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ABSTRACT 

Today's  simulation  technology  allows  warfighters  to  participate  in  a  continuous  training  cycle 
to  maintain  a  high  state  of  combat  readiness  by  using  cost-effective  simulation  alternatives  in 
conjunction  with  live-fly  operations  and  training  missions.  In  the  USA  current  development  of 
Live,  Virtual,  and  Constructive  (LVC)  systems  for  training  and  mission  rehearsal  and  the 
rapid  advancement  of  networking  technologies  and  protocol  standards /  architectures  have 
contributed  to  a  synthetic  environment  where  multi-force  Distributed  Mission  Operations 
(DMO)  joint/coalition  exercises  have  become  an  everyday  reality. 

For  the  ADF  to  participate  in  such  a  capability  corporate  interoperability  standards,  processes, 
common  applications  and  databases  need  to  be  developed.  This  report  discusses  a  strategy  to 
enable  the  ADF  to  begin  to  progress  towards  such  a  highly  interoperable,  LVC  synthetic 
environment  where  a  first  important  step  is  the  development  of  a  suitable  set  of  ADF 
corporate  LVC  interoperability  standards. 
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An  Air  Operations  Division  Live,  Virtual,  and 
Constructive  (LVC)  Corporate  Interoperability 
Standards  Development  Strategy 


Executive  Summary 


Today's  simulation  technology  allows  warfighters  to  participate  in  a  continuous 
training  cycle  to  maintain  a  high  state  of  combat  readiness  by  using  cost- 
effective  simulation  alternatives  in  conjunction  with  live-fly  operations  and 
training  missions.  In  the  US  current  development  of  Live,  Virtual,  and 
Constructive  (LVC)  systems  for  training  and  mission  rehearsal,  and  the  rapid 
advancement  of  networking  technologies  and  protocol  standards/ architectures 
have  contributed  to  a  synthetic  environment  where  multi-force  Distributed 
Mission  Operations  (DMO)  joint/coalition  exercises  have  become  an  everyday 
reality. 

Recently  the  US  DoD  Live- Virtual-Constructive  Architecture  Roadmap 
(LVCAR)  Study  was  completed.  The  purpose  of  this  study  was  to  develop  a 
future  vision  and  supporting  strategy  to  achieve  significant  interoperability 
improvements  in  LVC  simulation  environments. 

The  LVCAR  Study  concluded  that  the  best  way  forward  is  to  enhance  the 
interoperability  of  mixed-architecture  events,  while  preserving  options  and 
positioning  the  community  for  some  degree  of  architecture  convergence  in  the 
future.  These  objectives  are  founded  on  the  idea  that  having  multiple 
architectures  available  for  use  is  desirable  and  that  the  best  way  forward  is  to 
take  actions  that  can  reduce  or  eliminate  barriers  to  interoperability  between 
existing  architectures  and  protocols.  This  strategy  acknowledges  that  the 
existing  architectures  have  been  created,  are  evolving,  and  are  being  maintained 
to  meet  the  specific  needs  of  their  constituent  communities.  Elimination  of  any 
architecture  should  only  occur  as  a  natural  result  of  disuse.  Modification  and 
management  of  the  existing  architectures  are  left  to  the  owning  communities  as 
the  best  option  to  ensure  meeting  the  needs  of  the  various  user  communities, 
both  throughout  the  US  DoD  and  amongst  coalition  partners.  To  resolve 
interoperability  problems,  efforts  should  be  directed  towards  creating  and 
providing  standard  resources,  such  as  common  gateways,  common 
componentised  object  models,  and  common  federation  agreements.  These  can 
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resolve  problems  identified  and  render  integration  of  the  multiple  architectures 
through  an  efficient  and  nearly  transparent  process  by  creating  the  perception 
of  a  single  architecture  that  supports  all  of  the  diverse  simulation  systems. 
Thus,  the  systems  will  actually  be  serviced  by  an  "architecture  of  architectures", 
comprised  of  as  many  different  architectures  and  protocols  as  are  required  to 
interconnect  the  participating  simulation  systems. 

This  report  discusses  a  strategy  to  enable  the  ADF  to  begin  to  progress  towards 
such  a  highly  interoperable,  LVC  synthetic  environment  where  a  first  important 
step  is  the  development  of  a  suitable  set  of  ADF  corporate,  LVC  interoperability 
standards. 
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1.  Introduction 


Today's  modern  simulation  technology  allows  war-fighters  to  participate  in  a  continuous 
training  cycle  and  maintain  a  high  state  of  combat  readiness  by  using  cost-effective  simulation 
alternatives  in  conjunction  with  live-fly  operations  and  training  missions.  Current 
development  of  live,  virtual,  and  constructive  (LVC)  systems  for  training  and  mission 
rehearsal,  the  rapid  advancement  of  networking  technologies  and  protocol 
standards/ architectures  such  as  Distributed  Interactive  Simulation  (DIS)  [DIS  (1995)],  [DIS 
(1998)]  and  High  Level  Architecture  (HLA)  [HLA  (2000)-l],  [HLA  (2000)-2],  [HLA  (2000)-3], 
[HLA  (2003)]  have  all  contributed  to  an  environment  where  highly-distributed  training, 
mission  rehearsal,  operations  support,  and  multi-force  Distributed  Mission  Operations  (DMO) 
joint/ coalition  exercises  have  become  a  reality  [Portrey]. 


1.1  An  AOD  Mission  Training  Centre,  Capability  Concept  Demonstrator 

In  the  Australian  Defence  Force  (ADF)  the  RAAF  does  not  yet  use  LVC  interoperability. 

In  a  recent  DSTO  report  [Zalcman  (2010)]  an  Air  Operations  Division  (AOD)  Mission  Training 
Centre,  Capability  Concept  Demonstrator  (AOD  MTC  CCD)  programme,  similar  to  that 
developed  by  the  UK  MOD  Mission  Training  through  Distributed  Simulation  (MTDS) 
programme,  was  proposed. 

The  objectives  of  such  an  AOD  MTC  CCD  programme  will  be 

•  To  study  various  elements  of  Joint  and  Coalition,  Live- Virtual-Constructive  (LVC), 
Synthetic  Range  training  to  provide  guidance  on  technical  and  operational  issues  to 
assist  the  RAAF  to  migrate  towards  a  highly  interoperable,  LVC  corporate  synthetic 
environment  (Synthetic  Range)  to  assist  and  enable  the  RAAF  to  develop  a  training 
focused,  DMO  compliant  RAAF  Mission  Training  Centre  capability; 

•  To  do  experimentation,  research  and  development  to  help  the  ADF  and  RAAF 
develop  corporate  interoperability  standards  that  are  compliant  with  USAF  DMO 
standards.  These  standards  (the  Synthetic  Range  Interoperability  Model)  will  form  the 
advanced  distributed  simulation  infrastructure  (ie  a  standards  based  approach)  upon 
which  the  AOD  MTC  CCD  (and  eventually  the  RAAF  MTC)  will  be  developed.  This 
work  can  then  be  used  to  reduce  risk  and  cost  when  acquiring  future  ADF  LVC 
components,  training  systems  and  operational  platforms  with  LVC  capabilities;  and 

•  Test,  evaluate  and/ or  develop  re-usable  LVC  Mission  Training  Centre  components 
(Blue,  Red  and  White  Forces  Computer  Generated  Forces  (CGF)  applications.  Loggers, 
After- Action-Review  applications.  Situation  Awareness  applications,  etc)  which  could 
be  used  (ie  re-used)  to  reduce  cost  and  risk  for  current  and  future  ADF  and  RAAF 
training  systems  and  future  operational  platforms  with  LVC  interfaces. 
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1.2  The  USA  DoD  Live-Virtual-Constructive  Architecture  Roadmap  Study 

The  report  proposing  the  AOD  MTC  CCD  programme  [Zalcman  (2010)]  was  produced  before 
the  recent  release  of  the  USA  DoD  Live-Virtual-Constructive  Architecture  Roadmap  (LVCAR) 
Study  [LVCAR-1  ],  [LVCAR-2],  The  purpose  of  this  LVCAR  study  was  to  develop  a  future 
vision  and  supporting  strategy  to  achieve  significant  interoperability  improvements  in  LVC 
synthetic  environments.  To  support  the  implementation  of  this  strategy  the  LVCAR  study 
specifies  near-,  mid-,  and  long-term  actions  that  collectively  delineate  a  roadmap  to  guide  the 
evolution  from  the  current  state  of  LVC  environment  development  and  achieve  the  desired 
future  vision.  The  Roadmap  addresses  three  main  areas  of  concern:  the  desired  future 
integrating  architecture(s);  the  desired  business  model(s);  and  the  manner  in  which  standards 
should  be  evolved  and  compliance  evaluated. 

The  LVCAR  Study  concluded  that  the  best  way  forward  is  to  enhance  the  interoperability  of 
mixed-architecture  events,  while  preserving  options  and  positioning  the  community  for  some 
degree  of  architecture  convergence  in  the  future.  This  strategy  acknowledges  that  existing 
architectures  have  been  created,  are  evolving,  and  are  being  maintained  to  meet  the  specific 
needs  of  their  constituent  communities.  Efforts  should  be  directed  towards  creating  and 
providing  standard  resources,  such  as  common  gateways,  common  componentised  object 
models,  and  common  federation  agreements.  This  will  create  the  perception  of  a  single 
architecture  that  supports  all  of  the  diverse  simulation  systems  where  systems  will  actually  be 
serviced  by  an  "architecture  of  architectures",  comprised  of  as  many  different  architectures 
and  protocols  as  are  required  to  interconnect  the  participating  simulation  systems. 


1.3  The  Concept  of  the  Synthetic  Range  and  the  Synthetic  Range 
Interoperability  Model 

The  Concept  of  the  Synthetic  Range,  and  its  associated  Synthetic  Range  Interoperability 
Model,  has  been  previously  reported  in  DSTO  Reports  and  conference  papers  (see  [Zalcman 
(2010)]).  The  Concept  of  the  Synthetic  Range  and  the  Synthetic  Range  Interoperability  Model 
support  the  conclusions  and  recommendations  of  the  LVCAR  Study  and  these  conclusions 
and  recommendations  are  discussed  in  this  current  report. 

For  the  ADF  to  participate  in  multi-force  Distributed  Mission  Operations  (DMO) 
joint/ coalition  exercises,  ADF  corporate  interoperability  standards,  common  applications, 
processes  and  databases  need  to  be  developed.  This  report  discusses  a  strategy  to  enable  the 
ADF  to  begin  to  progress  towards  a  highly  interoperable,  LVC  synthetic  environment  where  a 
first  important  step  is  the  development  of  a  suitable  set  of  corporate  LVC  interoperability 
standards. 
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1.4  How  This  Report  is  Structured 

The  Concept  of  the  Synthetic  Range  and  the  Synthetic  Range  Interoperability  Model  that 
provide  a  simplified  way  of  understanding  how  military  Live,  Virtual  and  Constructive  (LVC) 
systems  can  interoperate  are  discussed  in  section  2  of  this  report. 

Section  3  defines  and  discusses  in  detail  the  three  main  types  of  Synthetic  Range  systems  (ie 
Live,  Virtual  and  Constructive  (LVC)  systems),  and  the  main,  commonly  used  LVC  Synthetic 
Range  system  interoperability  protocols/ standards  such  as  DIS,  HLA,  RPR-FOM,  TENA, 
SIMPLE,  SISO-J,  and  JREAP. 

The  recently  released  US  DoD  LVC  Architecture  Roadmap  (LVCAR)  Study  is  discussed  in 
section  4,  and  the  relevance  and  applicability  of  this  study  to  DSTO  and  the  ADF  is  discussed 
in  section  5. 

Section  6  discusses  what  LVC  interoperability  standards  are  used  in  coalition  nations 
including  modeling  and  simulation  interoperability  standards  recommended  by  NATO. 

Section  7  discusses  reducing  the  LVC  interoperability  model  further  to  a  more  cost-effective 
corporate  interoperability  model  that  can  be  applied  to  ADF  simulation  (ie  Virtual  and 
Constructive)  systems. 

How  we  use  the  findings  of  the  US  DoD  LVCAR  Study  to  proceed  to  develop  a  corporate 
ADF  Synthetic  Range  Interoperability  Model  is  discussed  in  section  8. 

Sections  9  and  10  discuss  compliance  with  a  Synthetic  Range  Interoperability  Model  and 
exactly  what  needs  to  go  into  the  beginnings  of  an  ADF  corporate  Synthetic  Range 
Interoperability  Model. 

Section  11  presents  some  DSTO  work  programmes  that  could  be  used  to  continue 
development  of  the  Corporate  ADF,  Synthetic  Range  Interoperability  Model  and  how  this 
work  can  then  be  used  to  develop  a  proposed  USAF  Distributed  Mission  Operations 
compliant  training  system  for  the  RAAF  that  would  begin  to  transform  how  the  RAAF  would 
do  its  future  training. 

Conclusions  and  recommendations  are  presented  in  sections  12  and  13. 


1.5  Section  Summary 

In  summary: 

•  What  Are  We  Doing  -  We  are  discussing  and  developing  a  strategy  to  produce  a  set  of 
minimalistic,  but  precise  and  unambiguous,  corporate  LVC  interoperability  standards 
to  progress  towards  a  highly  interoperable,  RAAF,  LVC  synthetic  environment; 

•  Why  Are  Doing  This  -  To  move  from  reducing  risk  towards  guaranteeing  LVC 
interoperability.  You  can  never  guarantee  100%  interoperability  but  the  objective  of 
developing  a  set  of  corporate  LVC  interoperability  standards  is  to  reduce  risk  and  to 
also  move  towards  guaranteeing  a  useable  level  of  out-the-box  interoperability  for 
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compliant  LVC  systems  when  they  are  delivered  to,  and  accepted  by,  the 
Commonwealth.  ADF/RAAF  high-fidelity  training  simulators  may  cost  between  $50 
and  $150  million.  Often  these  training  simulators  cannot  interoperate,  even  though 
they  were  specified  to  have  an  advanced  distributed  simulation  capability.  However 
they  may  not  have  been  specified  appropriately.  Once  an  appropriate  set  of 
minimalistic,  but  precise  and  unambiguous,  corporate  LVC  interoperability  standards 
have  been  developed,  a  corresponding  set  of  associated  Request  for  Tender  (RFT) 
specifications  and  Test  and  Acceptance  procedures  can  also  be  developed.  ADF  LVC 
systems  that  are  compliant  with  these  RFT  specifications  will  be  delivered  to  and,  once 
appropriate  compliance  testing  has  been  done,  accepted  by  the  Commonwealth  with  a 
useable  level  of  out-the-box  LVC  interoperability.  Such  a  standards  based  approach 
will  reduce  cost  and  risk  to  the  Commonwealth;  and 

•  How  Are  We  Doing  This  -  This  report  discusses  and  develops  a  strategy  that  shows 
exactly  how  a  set  of  precise  and  unambiguous,  corporate  LVC  interoperability 
standards  can  be  produced.  Appropriate  Test  and  Acceptance  procedures  and  RFT 
specifications  should  then  also  be  developed. 


2.  The  Concept  of  the  Synthetic  Range 


The  Concept  of  the  Synthetic  Range,  and  its  associated  Synthetic  Range  Interoperability 
Model,  provide  a  simplified  way  of  understanding  how  military  Live,  Virtual  and 
Constructive  (LVC)  systems  (see  section  3)  can  interoperate. 

Large-scale,  operational  (ie  Live)  exercises  provide  opportunities  to  train  crews  in  team  and 
inter-team  skills.  However  cost,  fatigue  life  concerns,  range  site  capabilities,  weather,  and 
frequency  of  event  limitations  make  this  only  a  partial  solution  to  crew  readiness  training.  A 
significant  gap  exists  between  training  obtained  using  stand-alone  simulators  and  training 
obtained  during  live  training  exercises  for  combat  crews.  Alternative  training  methods,  such 
as  Synthetic  Range,  LVC  training  (eg  USAF  DMO  Virtual  Flag  training  exercises),  should  be 
considered  to  cost-effectively  maintain  crew  readiness  [Blacklock  (2007)],  [Zalcman  (2010)]. 

Such  alternative  training  methods  would  allow  LVC  players  at  multiple  sites  to  participate  in 
synthetic  environment  training  exercises  ranging  from  individual  and  team  participation  to 
full  theatre-level  battles.  Advantages  arise  such  as  increased  value  and  efficiency  of  actual 
operational  platform  hours,  improved  communication  skills  in  a  joint  and  coalition 
environment,  and  an  increased  sense  of  trust  and  confidence  amongst  participants  [Cochrane]. 

Simulation,  when  combined  with  a  competency-based  training  program  and  live-flying 
training,  can  narrow  the  gap  between  continuation  training  and  combat  mission  readiness 
[Portrey]. 
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2.1  What  Is  A  Synthetic  Range? 

Synthetic  range  LVC  systems  can  interoperate  over  a  local  and/or  wide  area  network  in  a 
common  virtual  synthetic  environment  no  matter  where  these  systems  are  geographically 
located  throughout  the  world. 

Synthetic  Range  systems  can  share  the  same  common  ("ground  truth")  scenario  on  an 
advanced  distributed  simulation  network. 

In  a  synthetic  (LVC)  range  the  entirety  of  the  test  and  training  event  will  be  represented  in  a 
synthetic  environment  where  the  location  of  the  entities  in  the  synthetic  environment  may 
bear  no  relationship  to  the  real,  geographical  location  of  the  participating  LVC  systems. 

According  to  Daly  et  al.  [Daly] 

“Synthetic  environments  are  simulations  that  represent  activities  at  a  high  level  of 
realism.  These  environments  may  be  created  within  a  single  computer  or  over  a 
distributed  network  connected  by  local  and  wide  area  networks  and  are  augmented  by 
realistic  special  effects  and  accurate  behavioral  models.  They  allow  visualisation  of  and 
immersion  into,  the  environment  being  simulated”  [US]. 


2.2  What  Is  A  Synthetic  Range  Interoperability  Model? 

A  Synthetic  Range  Interoperability  Model  simplifies  the  development  of  a  synthetic  range 
architecture  and  thus  the  integration  of  participating  Synthetic  Range  compliant,  LVC 
systems. 

An  appropriate  set  of  ADF  corporate,  synthetic  range,  interoperability  standards  is  being 
developed  to  enhance  capability  and  reduce  risk  and  cost.  Once  such  a  set  of  Synthetic  Range 
Interoperability  Model  standards  has  been  developed,  a  set  of  complementary  test  and 
acceptance  procedures  can  also  be  developed  [Ross]. 

The  Synthetic  Range  Interoperability  Model  (Figure  1)  addresses  interoperability  from  three 
points  of  view: 

•  Advanced  Distributed  Simulation  interoperability; 

•  Tactical  Data  Link  interoperability;  and 

•  Radio  Communications  interoperability. 

Sharing  a  common  scenario  (ie  the  Ground  Truth)  on  an  advanced  distributed  simulation 
network  in  a  LVC  Synthetic  Environment  will  reduce  costs  considerably  by  not  requiring  real 
operational  platforms  for  every  entity  in  a  common  scenario.  The  potential  of  this  approach 
was  demonstrated  in  Australia  in  2007  with  LVC  participants  from  the  US  and  ADF 
participating  in  Exercise  Talisman  Sabre  07.  Further  savings  may  be  achieved  by  building 
distributed  (and  re-usable)  system  capability  and  functionality  using  smaller  (but  more 
dedicated)  distributed  simulation  applications  rather  than  creating  a  single  large  LVC 
software  system.  The  DSTO  developed  Air  Defence  Ground  Environment  SIMulator 
(ADGESIM)  RAAF  trainer  [Blacklock  (2006)],  [Blacklock  (2007)],  [Zalcman  (2005)],  [Zalcman 


UNCLASSIFIED 


5 


UNCLASSIFIED 


DSTO-GD-0645 

(2006)],  [Zalcman  (2008)]  uses  such  a  distributed  architecture  and  the  ADGESIM  applications 
are  actually  stand-alone,  independent  applications  that  can  be  reused  in  other  DIS  LVC 
simulation  systems. 

Supporting  real  (ie  Live)  Tactical  Data  Links  realistically  simulates  the  real  world  Network 
Centric  Warfare  (NCW)  environment  and  enhances  the  fidelity  and  capabilities  of  Synthetic 
Range  multi-player,  multiple  site  exercises. 

Voice  communication  is  the  common  variable  tying  LVC  entities  together  regardless  of  the 
operating  domain  -  it  is  a  basic  component  of  the  synthetic  battle  space  [Rumpel] . 

Note  that  the  architecture  /  interoperability  model  (Figure  1  and  Table  3)  is  a  minimalistic 
starting  point  -  it  does  not  preclude  later  enhancement  of  the  current  components  or  addition 
of  other  new  components  to  the  model  (ie  the  ADF  model)  or  to  a  specific  version  of  the 
model  (eg  a  RAN  Synthetic  Range  Interoperability  Model)  (see  section  9.4). 


Link  16  J-series  Messages  Network 


IEEE  1278.1  A  DIS  Network 


Figure  1  The  (Generic)  Synthetic  Range  Interoperability  Model. 

The  long  term  research  and  development  objectives  of  the  Synthetic  Range  are  to: 

•  Further  develop  the  Concept  of  the  Synthetic  Range; 

•  Develop  corporate  (ie  recommended  ADF)  Synthetic  Range  Interoperability  Model 
interoperability  standards;  and 


6 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0645 

•  Ensure  (through  Australian  Defence  Simulation  Office  /  Defence  Materiel 
Organisation  participation)  that  in  future  every  LVC  system  that  may  need  to 
interoperate  is  acquired  with  a  set  of  common  Synthetic  Range  Interoperability  Model 
capabilities  (ie  Gateways/ capabilities)  that  comply  with  ADF  corporate 
interoperability  standards  to  enable  a  common  level  of  LVC  interoperability  at  the 
time  of  "out-the-box"  system  delivery  and  acceptance  by  the  ADF. 


2.3  Section  Summary 

The  concept  of  the  Synthetic  Range  and  the  Synthetic  Range  Interoperability  Model  have  been 
discussed.  The  Synthetic  Range  Interoperability  Model  views  LVC  interoperability  from  three 
points  of  view: 

•  Advanced  Distributed  Simulation  interoperability; 

•  Tactical  Data  Link  interoperability;  and 

•  Radio  Communications  interoperability. 

The  objective  of  this  work  is  to  continue  development  of  an  ADF  Corporate  Synthetic  Range 
Interoperability  Model  (ie  a  set  of  ADF  Corporate  interoperability  standards)  that  will 
precisely  and  unambiguously  define  LVC  interoperability  parameters  that  will  be  specified 
when  acquiring  any  ADF  LVC  system.  Any  such  system  that  complies  with  the  recommended 
(ie  specified)  ADF  Corporate  Synthetic  Range  Interoperability  Model  should  be  delivered  and 
accepted  (ie  tested)  with  a  useful,  usable,  out-the-box  level  of  LVC  interoperability. 

Such  an  ADF  Corporate  Synthetic  Range  Interoperability  Model  will  result  in  reduced  cost 
and  risk  to  the  ADF  for  compliant  ADF  LVC  systems. 


3.  Live-Virtual-Constructive  INTEROPERABILITY 


3.1  Live- Virtual-Constructive  System  Types 

A  synthetic  range  system  can  be  broadly  classified  as  belonging  to  one  of  three  different  types 
of  systems  -  Live,  Virtual,  or  Constructive  (LVC)  [Zalcman  (2010)]  where: 

3.1.1  Live  Systems 

•  Live  systems  - 

>  Live  systems  are  "instrumented"  real-world,  operational  military  platforms. 
Instrumentation  (Embedded  or  On-Board-Training-Systems,  Air  Combat 
Manoeuvring  Instrumentation  (ACMI)  systems  [Cubic],  etc)  attached  to  these 
Live  systems  can  provide  information  such  as  location,  speed,  acceleration, 
system  orientation,  weapon  status,  etc.  to  the  synthetic  range  distributed 
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simulation  network  in  real-time  such  that  this  data  can  interoperate  in  the 
synthetic  range  virtual  environment.  Live  system  data  may  need  to  be 
distributed  via  radio  telemetry  to  a  dedicated,  ground  station  where  it  is 
distributed  to  other  synthetic  range  participants  using  standardised, 
simulation  network  protocols.  In  the  same  way,  data  from  other  synthetic 
range  participants  must  be  converted  from  the  standardised  simulation 
network  protocols  and  provided  in  an  appropriate  form  to  the  Live,  synthetic 
range  compliant  systems; 

>  Live  training  exercises  real  people  using  real  equipment  in  a  real  environment; 
and 

>  Live  Simulation  involves  real  people  operating  real  systems  [NATO  M&S 
Vision],  The  Navy  conducts  this  type  of  training  at  sea  using  steaming  hours 
while  ships  are  under  way.  Daly  at  al.  [Daly]  differentiate  between  Synthetic 
training  (delivery  method)  that  occurs  with  real  people  using  real  equipment 
in  a  virtual  environment,  and  Live  training  that  occurs  using  the  same  real 
people  and  the  same  real  equipment  but  Live  training  occurs  in  the  real 
environment  not  a  virtual  environment. 

3.1.2  Virtual  Systems 

•  Virtual  systems  - 

>  Virtual  systems  comprise  training  and  experimentation  simulators  (Human-In- 
the-Loop  (HIL)  simulators)  that  are  crewed  by  people.  These  systems  may 
have  advanced  distributed  simulation  capabilities  that  use  simulation  network 
protocols.  However  some  form  of  common  connection  gateway  device  may  be 
required  to  convert  the  simulation  system  protocols  to  (required)  corporate 
standard,  synthetic  range,  interoperability  protocols; 

>  Virtual  training  exercises  real  people  using  simulated  equipment  in  a 
simulated  environment;  and 

>  Virtual  Simulation  involves  real  people  operating  simulated  systems.  Virtual 
training  usually  involves  wargaming  in-house  (in  a  building)  using  simulation 
equipment. 

3.1.3  Constructive  Systems 

•  Constructive  systems  - 

>  Constructive  systems  are  entirely  synthetic  representations  of  both  platforms 
and  people  -  they  act  according  to  software  rules  rather  than  through  human 
direction; 

>  Constructive  training  exercises  simulated  people  using  simulated  equipment 
in  a  simulated  environment.  Constructive  Modeling  or  Simulation  involves 
simulated  people  operating  simulated  systems  [NATO  M&S  Vision],  It  is  the 
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most  "artificial"  of  all  active  (i.e.,  non-classroom)  training  and  it  involves  only 
the  practical  application  of  cognitive  skills;  and 

>  Constructive  training  can  include  personal  computer  (PC)  or  tabletop 
wargaming.  This  training  focuses  primarily  on  strategic,  operational,  or  tactical 
decision-making. 

The  commonly  used  definitions  of  Live,  Virtual  and  Constructive  Synthetic  Range  systems  are 
shown  in  Table  1. 

To  achieve  interoperability  among  LVC  systems  within  a  common  scenario  requires 
compliance  with  an  agreed  set  of  interoperability  standards  including  network  infrastructure, 
data,  interoperability  protocols,  platform/ environment  representation,  etc  [Aldinger], 
[Zalcman  (2010)].  This  requires  the  development  of  an  interoperability  model  (the  Synthetic 
Range  Interoperability  Model)  that  is  a  crucial  part  of  the  synthetic  range  architecture.  All 
synthetic  range  systems  that  are  compliant  with  this  set  of  interoperability  standards  (ie  the 
interoperability  model)  should  be  (highly)  interoperable  regardless  of  whether  the  systems  are 
Live,  Virtual  or  Constructive  systems.  How  interoperable  such  systems  are  depends  on  the 
"completeness"  of  the  interoperability  model  used. 

Table  1  More  Commonly  Used  LVC  System  Definitions. 


( - \ 

•  Live  =  real  people  in  real  locations  using  real  equipment 

•  Virtual  Simulation  =  real  people  in  simulators 

•  Constructive  Simulation  =  simulated  entities  in  a  simulated  environment 

\ _ 


A  graphical  representation  of  a  LVC  Synthetic  Range  environment  is  shown  in  Figure  2. 
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Synthetic 

Forces 


Virtual  Simulators 
Simulations 


Live/Real  World  C2 


Figure  2  A  Graphic  of  an  LVC  Synthetic  Environment 

Up  till  now  most  participants  in  distributed  simulation  exercises  would  normally  only  be 
expected  to  be  Virtual  or  Constructive  systems  (ie  nodes)  however  an  appropriate  strategy 
should  consider  full  LVC  interoperability  (ie  include  Live  platform  interoperability). 

3.2  LVC  Interoperability  Standards 


The  NATO  Modelling  and  Simulation  Standards  Profile  (NMSSP)  defines  interoperability 
among  simulations  (should  be  LVC  systems)  as 

“The  capability  for  simulations  to  physically  interconnect,  to  provide  (and  receive) 
sendees  to  (and  from)  other  simulations,  to  use  these  exchanged  services  in  order  to 
effectively  work  together.  This  definition  refers  mainly  to  “technical  interoperability  ”  that 
means  the  possibility  to  physically  interconnect  then  communicate.  A  lot  of  additional 
work  has  to  be  done  after  interconnection  is  ensured,  to  reach  higher  levels  of 
interoperability  (semantic  or  substantive  interoperability)  ”  [NATO  NMSSP]. 

3.2.1  Distributed  Interactive  Simulation  (DIS) 


DIS  -  The  NATO  Modelling  and  Simulation  Standards  Profile  describes  DIS  (IEEE  1278.1/ A 
Distributive  Interactive  Simulation  [DIS  (1995)],  [DIS  (1998)])  as: 

•  DIS  is  an  interoperability  standard  based  on  exchanges  of  formatted  messages  between 
simulation  applications.  Simulation  state  information  and  interactions  are  encoded  in 
messages  known  as  Protocol  Data  Units  (PDUs)  and  are  exchanged  between  hosts 
using  existing  transport  layer  protocols,  though  normally  broadcast  User  Datagram 
Protocol  (UDP)  is  used; 

•  More  than  15  years  of  use  in  many  NATO  countries;  very  mature  technology;  and 


10 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-GD-0645 

•  DIS  is  a  protocol  for  linking  simulations  of  various  types  at  multiple  locations  to  create 
realistic,  complex,  virtual  worlds  for  the  simulation  of  highly  interactive  activities.  This 
protocol  can  be  used  to  bring  together  systems  built  for  separate  purposes,  technologies 
from  different  eras,  products  from  various  vendors,  and  platforms  from  various 
services,  and  permits  them  to  interoperate.  DIS  exercises  are  intended  to  support  a 
mixture  of  virtual  entities  with  computer  controlled  behaviour  (computer  generated 
forces),  virtual  entities  with  live  operators  (human-in-the-loop  simulators),  live  entities 
(operational  platforms  and  test  and  evaluation  systems),  and  constructive  entities 
(wargames  and  other  automated  simulations).  There  are  many  operational 
implementations  in  various  nations.  The  best  example  is  the  US  Air  Force  Distributed 
Mission  Operation  (DMO)  programme.  The  primary  limitation  of  this  standard  is  that  it 
is  applicable  to  only  real  time  (simulated  time  =  wall  clock  time)  simulation  and  has  a 
fixed  object  model  defined  at  the  platform  level. 

3.2.2  High  Level  Architecture  (HLA) 

The  NATO  Modelling  and  Simulation  Standards  Profile  describes  HLA  (IEEE  1516  High  Level 
Architecture  [HLA  (2000)-l],  [HLA  (2000)-2],  [HLA  (2000)-3j)  as: 

•  The  High  Level  Architecture  (HLA)  for  M&S  is  defined  by  three  technical  documents. 
The  standards  contained  in  this  architecture  are  interrelated  and  need  to  be  considered 
as  a  product  set,  as  a  change  in  one  is  likely  to  have  an  impact  on  the  others.  As  such, 
HLA  is  an  integrated  approach  that  has  been  developed  to  provide  a  common 
architecture  for  simulation; 

•  The  Framework  and  Rules  [HLA  (2000)-l]  is  the  capstone  document  for  a  family  of 
related  HLA  standards.  It  defines  the  HLA,  its  components,  and  the  rules  that  outline 
the  responsibilities  of  HLA  federates  and  federations  to  ensure  a  consistent 
implementation.  The  Federate  Interface  Specification  [HLA  (2000)-2]  defines  the 
standard  services  of,  and  interfaces  to,  the  HLA  Runtime  Infrastructure  (RTI).  These 
services  are  used  by  the  interacting  simulations  to  achieve  a  coordinated  exchange  of 
information  when  they  participate  in  a  distributed  federation.  The  Object  Model 
Template  provides  a  specification  [HLA  (2000)-3]  for  describing  object  models  that 
define  the  information  produced  or  required  by  a  simulation  application,  and  for 
reconciling  definitions  among  simulations  to  produce  a  common  data  model  for  mutual 
interoperation; 

•  The  High  Level  Architecture  is  a  technical  architecture  developed  to  facilitate  the  reuse 
and  interoperation  of  simulation  systems  and  assets.  The  HLA  provides  a  general 
framework  within  which  developers  can  structure  and  describe  their  simulation 
systems  and/  or  assets,  and  interoperate  with  other  simulation  systems  and  assets. 

•  The  HLA  consists  of  three  main  components: 

>  The  first  component  specifies  the  Framework  and  Rules; 

>  The  second  component  provides  the  interface  specifications;  and 

>  The  third  component  describes  the  Federation  Object  Model  requirements  in 
the  Object  Model  Template  (OMT)  Specification; 
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•  HLA  is  widely  implemented  within  NATO  and  PfP  (Partnership  for  Peace)  nations. 
There  are  a  variety  of  commercial,  open  source  and  government  support  tools;  and 

•  HLA  is  not  "plug  and  play".  Some  parts  of  the  standards  are  left  open  to  the  RTI 
implementer,  thus  different  RTIs  are  not  guaranteed  to  interoperate  (ie  in  most  cases 
they  will  not  interoperate). 

3.2.3  The  Real-time  Platform-level  Reference-Federation  Object  Model  (RPR-FOM) 

While  the  HLA  Standards  dictate  how  federates  exchange  data,  it  is  a  Federation  Object 
Model  (FOM)  that  dictates  what  data  is  being  exchanged  in  a  particular  federation.  HLA  does 
not  mandate  the  use  of  any  particular  FOM  however  several  "reference  FOMs"  have  been 
developed  to  promote  a-priori  interoperability.  That  is,  in  order  to  communicate,  a  set  of 
federates  must  agree  on  a  common  FOM  (among  other  things).  Reference  FOMs  provide 
ready-made  FOMs  that  are  supported  by  a  wide  variety  of  tools  and  federates.  Reference 
FOMs  can  be  used  as-is  or  can  be  extended  to  add  new  simulation  concepts  that  are  specific  to 
a  particular  federation  or  simulation  domain; 

The  NATO  Modelling  and  Simulation  Standards  Profile  describes  the  RPR-FOM  Standard  for 
Real-time  Platform-level  Reference  Federation  Object  Model  (SISO-STD-OOl. 1-1999)  [RPR- 
FOM-1]  as: 

•  The  RPR-FOM  is  a  reference  FOM  that  defines  HLA  classes,  attributes  and  parameters 
that  are  appropriate  for  real-time,  platform-level  simulations.  Applications  that  have 
previously  used  DIS  (or  would  have  considered  using  DIS),  often  use  the  RPR-FOM  (or 
a  derivative  of  it)  when  interoperating  using  HLA.  The  RPR  FOM  was  developed  by  a 
SISO  Product  Development  Group  (PDG).  Its  goal  was  not  to  just  implement  the  DIS 
Protocol  Data  Unit  structures  within  HLA  object  and  interaction  classes,  but  rather  to 
provide  an  intelligent  translation  of  the  concepts  used  in  DIS  to  a  HLA  environment; 

•  A  companion  document,  known  as  the  GRIM  (Guidance,  Rationale,  and 
Interoperability  Mappings)  provides  documentation  for  the  RPR  FOM.  This  document 
is  known  as  SISO-STD-OOl.1-1999  [RPR-FOM  -  1.1]; 

•  RPR-FOM  1.0  [RPR-FOM  - 1]  is  based  on  the  IEEE  1278.1-1995  [DIS  (1995)]  version  of 
the  DIS  Standard  and  became  a  SISO  standard  in  1999.  It  corresponds  to  the  US  DoD 
NG  1.3  version  of  HLA. 

•  RPR-FOM  2.0  [RPR-FOM  -  2]  was  to  correspond  to  the  IEEE  1278.1/ A  version  of  DIS 
[DIS  (1998)].  However  the  SISO  balloting  process  was  never  completed  due  to  a  lack  of 
SISO  contributors; 

•  Enables  federations  of  real-time,  platform-based  simulations,  typically  allowing  DIS 
users  to  achieve  HLA  compliance; 

•  Is  in  use  in  many  HLA  federations;  and 

•  Limitations  of  this  Standard:  Mainly  targeted  to  entity-level  simulations. 
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3.2.4  The  Test  and  Training  Enabling  Architecture  (TENA) 

The  NATO  Modelling  and  Simulation  Standards  Profile  describes  TENA  (The  Test  and 
Training  Enabling  Architecture)  as: 

•  TENA  is  a  product  of  the  Foundation  Initiative  2010  (FI  2010)  project,  sponsored  by  the 
Central  Test  and  Evaluation  Investment  Program.  The  core  of  TENA  is  the  TENA 
Common  Infrastructure,  including  the  TENA  Middleware,  the  TENA  Repository  and 
the  TENA  Logical  Range  Data  Archive.  TENA  also  specifies  the  existence  of  a  number 
of  tools  and  utilities,  including  those  necessary  for  the  efficient  creation  of  a  logical 
range.  Range  instrumentation  systems  (also  called  range  resource  applications)  and  all 
of  the  tools  interact  with  the  common  infrastructure  through  the  medium  of  the  TENA 
object  model.  The  TENA  object  model  encodes  all  of  the  information  that  is  transferred 
between  systems  during  a  range  event.  It  is  the  common  language  with  which  all 
TENA  applications  communicate; 

•  Is  widely  used  within  the  US  range  community  and  actively  managed  through  an 
Architecture  Management  Team; 

•  Can  be  used  for  Live  Range  Interoperability,  LVC  Interoperability  and  Test 
Interoperability; 

•  The  initial  implementation  for  TENA  is  to  interoperate  with  US  National  Test  and 
Training  Ranges.  It  has  been  used  at  USJFCOM  to  incorporate  Live  and  Range  assets 
into  LVC  Training  exercises  (see  https:/ / www.tena-sda.org/ display/ intro/  news  for 
extensive  listing  of  program  usage);  and 

•  Is  currently  targeted  for  real-time  applications  only. 

3.2.5  SIMPLE 

The  NATO  Modelling  and  Simulation  Standards  Profile  describes  SIMPLE  (Standard  Interface 
for  Multiple  Platform  Link  Evaluation  -  STANAG  5602)  as: 

•  STANAG  5602  (SIMPLE)  provides  specifications  for  a  common  standard  to 
interconnect  ground  rigs  of  all  types  (e.g.  simulation,  integration  facilities  etc.)  for  the 
purpose  of  Tactical  Data  Link  (TDL)  Interoperability  testing; 

•  SIMPLE  supports  DIS  (but  not  LILA)  by: 

>  Enabling  DIS  PDUs  to  be  encapsulated  and  distributed  around  a  SIMPLE 
network  within  the  SIMPLE  protocol  packets:  and 

>  DIS  can  be  used  to  stimulate  SIMPLE  systems  for  testing  purposes; 

•  The  second  version  of  SIMPLE  was  promulgated  in  2006  and  the  next  version  (edition 
3)  is  under  ratification.  The  standard  is  evolving  thanks  to  feedback  coming  from  a 
large  base  of  users; 

•  The  SIMPLE  STANAG  (5602)  specifies  the  requirements  for  transfer  of  data  between 
remote  sites  in  different  locations  to  support  interoperability  testing  of  TDL 
implementations  in  the  different  platforms  of  NATO  Nations  and  Organisations; 
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•  Is  used  in  NATO;  and 

•  Is  not  fully/ only  targeted  to  simulation  interoperability.  It  was  not  originally  designed 
to  model  Link-16  for  training,  but  for  testing  only.  The  standard  does  not  model  all 
Link-16  capabilities,  such  as  net  entry,  net  exit,  perceived  versus  actual  position,  Link- 
16  relay,  message  encryption,  and  Time  Slot  Reallocation.  It  is  applicable  to  real-time 
simulation  applications. 

3.2.6  SISO-J 

The  NATO  Modelling  and  Simulation  Standards  Profile  describes  SISO-J  (Tactical  Data 
Information  Link  -  Technical  Advice  and  Lexicon  for  Enabling  Simulations  -  referred  to  as 
SISO-STD-002-2006)  [SISO-STD-002-2006]  as: 

•  There  are  immediate  operational  requirements  for  existing  military  simulations  to 
exchange  Link-16  data  using  a  single  interoperability  standard.  The  purpose  of  this 
standard  is  to  meet  this  need  by  providing  a  standard  for  simulating  the  Link-16 
protocol.  This  standard  defines  five  fidelity  levels,  from  message  exchange  only  to 
Link-16  network  modelling,  including  Return  Trip  Timing  messages.  Net  Entry  and 
Exit,  Actual  versus  Perceived  location,  and  encryption  methods.  The  SISO  Link-16 
standard  interoperates  in  DIS  using  the  Transmitter  and  Signal  PDUs,  and  in  HLA 
under  the  equivalent  BOM  and  RPR  FOM  paradigms; 

•  In  use  for  some  years  by  the  US  Air  Force,  Navy,  and  Marines  for  distributed 
simulation  training; 

•  The  main  objective  of  the  SISO-J  protocol  is  to  establish  a  standard  for  Link-16  message 
exchange  and  JTIDS  (Joint  Tactical  Information  Distribution  System)  network 
simulation  in  the  DIS  and  HLA  interoperability  paradigms.  The  intent  is  to  prescribe 
the  content  of  the  standard  fields  of  the  Transmitter  and  Signal  PDUs  (and  the 
corresponding  HLA  RPR-FOM  Transmitter  Object  and  Signal  Interactions)  and 
establish  procedures  for  their  use.  Compliance  with  these  procedures  facilitates 
interoperability  among  Link-16  simulation  systems; 

•  Is  in  use  in  NATO  and  partner  countries;  and 

•  This  standard  applies  only  to  Link-16/ JTIDS/MIDS.  It  does  not  address  Link-16  over 
satellite  communications  (SATCOM). 

3.2.7  JREAP 

The  NATO  Modelling  and  Simulation  Standards  Profile  does  not  include  the  JREAP  (Joint 
Range  Extension  Applications  Protocol  MIL-STD-3011)  [MIL-STD-3011]  standard.  JREAP 
extends  the  range  of  Tactical  Digital  Information  Links  by  permitting  tactical  data  messages  to 
be  transmitted  over  long-distance  networks.  According  to  Wikipedia  [Wikipedia]: 

•  JREAP  was  developed  due  to  the  need  to  communicate  data  over  long  distances 
without  degradation  to  the  message  format  or  content.  JREAP  takes  the  message  from 
its  original  format  and  changes  the  protocol  so  that  the  message  can  be  transmitted 
over  Beyond  Line-of-Sight  media; 
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•  JREAP  is  the  protocol  and  message  structure  for  the  transmission  and  reception  of  pre¬ 
formatted  messages  over  communications  media  other  than  those  for  which  these 
messages  were  designed; 

•  JREAP  provides  a  foundation  for  Joint  Range  Extension  (JRE)  of  Link-16  and  other 
tactical  data  links  to  overcome  the  line-of-sight  limitations  of  radio  terminals  such  as 
the  JTIDS  and  MIDS  TDL  communications  systems,  and  extends  coverage  of  these  data 
links  through  the  use  of  long-haul  media; 

•  JREAP-A  is  an  encrypted  satellite  link  using  a  serial  data  interface  to  exchange 
information  in  a  half-duplex  or  broadcast  mode; 

•  JREAP-B  is  a  secure  synchronous  or  asynchronous  point-to-point  serial  data  interface 
used  to  exchange  information  in  a  full-duplex  data-transparent  mode;  and 

•  JREAP-C  is  a  secure  data  link  interface  that  encapsulates  JREAP  over  IP  using  IP  based 
networks  for  the  exchange  of  information. 

3.3  Section  Summary 

The  three  main  types  of  Synthetic  Range  systems  (Live,  Virtual  and  Constructive)  have  been 
defined  and  discussed. 

Commonly  used  Synthetic  Range  LVC  system  interoperability  protocols/ standards  (ie  de- 
facto  standard  protocols  such  as  DIS,  HLA,  RPR-FOM,  TENA,  SIMPLE,  SISO-J,  and  JREAP) 
have  also  been  defined  and  discussed  in  detail. 


4.  The  USA  DOD  LVC  Architecture  Roadmap 


4.1  Purpose  and  Scope  of  the  USA  DoD  LVC  Architecture  Roadmap 
(LVCAR)  Study 

The  purpose  of  the  Live-Virtual-Constructive  Architecture  Roadmap  (LVCAR)  Study  was  to 
develop  a  future  vision  and  supporting  strategy  to  achieve  significant  interoperability 
improvements  in  LVC  simulation  environments.  To  support  the  implementation  of  this 
strategy  the  LVCAR  study  specifies  near-,  mid-,  and  long-term  actions  that  collectively 
delineate  a  roadmap  to  guide  the  evolution  from  the  current  state  of  LVC  environment 
development  to  achieve  the  desired  future  vision.  The  Roadmap  addresses  three  main  areas  of 
concern;  the  desired  future  integrating  architecture(s),  the  desired  business  model(s),  and  the 
manner  in  which  standards  should  be  evolved  and  compliance  evaluated. 

The  LVCAR  Roadmap  is  intended  to  be  a  living  dynamic  document,  to  stimulate  a  process  of 
continual  improvement  to  guide  actions  and  decision-making  on  the  development  and 
employment  of  LVC  environments  across  the  DoD.  For  context  and  scope,  this  Roadmap  sets 
the  course  for  achieving  the  US  DoD's  vision  for  LVC  integrating  architectures  over  the  next 
10  years.  Understandably,  in  a  field  dependent  on  technologies  and  processes  from  so  many 
other  organizations,  mid-course  adjustments  are  anticipated. 
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4.2  An  Underlying  and  Fundamental  Aspect  of  the  Problem 

According  to  the  LVCAR  Study  documentation  there  is  a  perception  by  many  in  the  LVC 
community  that  interoperability  will  be  much  easier  (and  less  costly)  if  there  was  only  a  single 
architecture  available  for  use.  There  would  be  benefit  by  eliminating  the  costs  associated  with 
maintaining  multiple  architectures  with  overlapping  capabilities.  The  desire  to  achieve  such  a 
single-architecture  state  is  based  on  a  number  of  difficulties  in  the  current  situation  that  can  be 
directly  attributed  to  the  existence  of  these  multiple  architectures  [LVCAR-1], 

First,  problems  arise  whenever  multiple  architectures  must  be  integrated  for  use  in  a  single 
event.  In  many  cases,  such  mixed-architecture  events  can  only  use  the  set  of  capabilities 
common  across  all  of  the  architectures  to  be  included  in  the  event.  This  is  sometimes 
described  as  the  "dumbing  down"  of  the  more  capable  architectures  because  the  full  range  of 
unique  capabilities  they  offer  (e.g.,  more  advanced  capabilities  such  as  repeatability, 
communications  bandwidth  efficiency,  ownership  transfer)  cannot  be  used  across  the  entire 
set  of  participating  systems.  Further,  the  costs  required  to  integrate  architectures  rarely 
contribute  directly  to  achieving  simulation  event  goals.  Instead,  the  associated  costs  usually 
provide  point  solutions,  versions  of  which  have  likely  been  created  in  the  past  and  probably 
will  be  paid  for,  and  created,  again  in  the  future.  Thus,  the  integration  costs  are  viewed  as 
recurring  expenses  that  contribute  little  to  achieving  event  goals  and  should  thus  be 
eliminated.  Mixed  architectures  impede  "plug-and-play".  Mixed  architecture  events  are  more 
expensive  to  integrate,  result  in  overall  slower  systems,  and  it  is  sometimes  impractical 
(difficult)  to  construct  simulation  events  using  any  of  the  wide  range  of  assets  (e.g., 
simulations,  simulators,  labs,  ranges,  C4ISR  systems,  etc.)  available  in  the  DoD  inventory.  In 
such  events  participating  assets  may  not  be  chosen  based  purely  on  functional  merit  alone 
because  systems  may  be  constrained  to  be  compatible  with  a  specific  architecture.  If  the  "out- 
of-the-box"  compatibility  constraints  are  ignored,  some  amount  of  additional  cost  (time, 
dollars,  etc.)  often  follows.  Typically,  such  costs  cannot  be  ignored,  so  events  will  be  designed 
that  only  consider  compatible  systems. 

However,  while  each  of  these  disadvantages  can  be  attributed  to  the  existence  and  use  of 
multiple  architectures,  their  existence  does  not  necessarily  justify  the  assumption  that  ridding 
the  DoD  of  all  but  one  architecture  would  result  in  an  optimal  state  of  affairs.  According  to  the 
LVCAR  Study  there  are  at  least  five  main  factors  indicating  that  such  an  assumption  appears 
to  be  fallacious.  First,  legacy  systems  will  continue  to  be  used  and  it  is  unlikely  that  these 
systems  will  upgrade  to  using  a  new  or  different  architecture.  Thus,  use  of  legacy  systems  is 
most  likely  to  preclude  the  possibility  of  ever  achieving  a  truly  "single-architecture"  state. 
Second,  use  of  a  single  architecture  may  still  require  the  use  of  supporting  bridges,  much  as 
use  of  different  RTIs  can  require  bridges  today.  Third,  gateways  will  be  required  for 
connecting  any  single  simulation  architecture  to  C4I  systems,  to  the  GIG,  or,  in  general,  to  any 
type  of  system  that  has  a  primary  purpose  outside  of  the  simulation  arena.  Fourth,  the 
alignment  of  a  family  of  simulations  on  a  single  architecture  represents  a  single  point  solution. 
Having  attained  such  standardisation,  history  points  to  the  likelihood  that  the  diverse  group 
of  simulation  users  will  quickly  diverge  into  specialisations,  leading  to  the  need  for  gateways 
to  bridge  their  differences.  Fifth,  the  selection  or  creation  of  a  single  architecture  assumes  that 
the  rapid  advances  of  the  commercial  software  industry  will  not  lead  to  a  better 
implementation  (ie  a  new  "better"  architecture)  in  the  future,  perhaps  based  on  a  Service- 
Oriented  Architecture  (SOA)  paradigm.  When  this  does  occur,  the  existing  standard 
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architecture  would  be  abandoned  by  users  who  have  needs  for  the  superior  architecture 
delivered  by  the  commercial  sources. 

The  simultaneous  existence  of  multiple  architectures  may  allow  benefits  that  are  less  likely  to 
be  achieved  in  a  single  architecture  state.  These  include:  1)  the  ability  to  support  multiple 
business  and  standards-use  communities  simultaneously  and;  2)  fostering  the  capability  to 
"use  the  right  tool  for  the  job",  avoiding  the  "one  size  fits  all"  problem.  Some  specific 
examples  include: 

•  DIS  (Distributed  Interactive  Simulation):  This  protocol  has  a  comparatively  low  barrier 
to  entry;  it  is  relatively  simple  to  learn  and  easy  to  use.  Also,  it  imposes  a  very  low 
overhead.  Whenever  simulation  events  do  not  require  using  more  advanced 
architectural  services  (such  as  time  management,  region-based  information  filtering, 
and  so  on),  DIS  offers  a  very  economical  solution  to  the  system  intercommunication 
problem; 

•  HLA  (High  Level  Architecture):  This  architecture  can  serve  a  disparate  collection  of 
simulation  systems,  including  those  that  require  advanced  architectural  services  and 
those  that  have  modest  requirements.  In  addition  to  its  large  US  user  base,  its  standing 
as  an  international  standard  has  resulted  in  a  high  level  of  use  in  the  coalition  partner 
countries,  facilitating  combined  simulation  events  that  include  multiple  nations; 

•  TENA  (Test  and  Training  Enabling  Architecture):  This  is  a  very  capable  architecture, 
offering  much  of  the  same  capability  as  HLA,  but  based  on  more  modern  object- 
oriented  technology.  TENA  middleware  is  offered  to  government  users  as 
Government-Off -The-Shelf  (GOTS),  unlike  HLA  that  must  be  purchased  on  a  per-seat 
basis;  and 

•  CTIA  (Common  Training  and  Instrumentation  Architecture) :  This  architecture  uses  the 
service-oriented  paradigm  and  is  unique  in  that  respect.  Also,  it  has  been  designed  to 
continue  providing  some  level  of  service  even  in  the  face  of  unreliable  communication 
networks.  It  also  provides  advanced  service  capabilities  and  an  "on-the-wire" 
specification  (instead  of  an  API-level  standard),  thus  offering  potentially  improved 
support  for  multiple  hardware  platforms,  operating  systems,  and  software 
development  languages. 

In  short,  the  existence  of  multiple  architectures  is  not  necessarily  an  undesirable  outcome  and, 
given  some  of  the  unique  benefits,  could  be  a  desirable  outcome  if  the  architectures  can  be 
easily  integrated. 

In  summary,  there  are  advantages  and  disadvantages  associated  with  the  number  of 
architectures  that  are  available  for  use.  There  is  no  paramount  advantage  or  disadvantage  that 
allows  one  to  immediately  recognise  the  best  possible  solution.  A  significant  problem  for  the 
LVCAR  effort  is  to  navigate  this  trade  space  to  arrive  at  an  achievable  solution  that  maximises 
the  benefit  for  all  concerned  while  not  exceeding  the  resources  that  will  be  necessary  to  realise 
that  solution. 
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4.3  Fundamental  Precepts 

As  the  LVCAR  Study  proceeded,  a  core  set  of  beliefs,  axiomatic  "meta-recommendations"  (ie 
fundamental  precepts)  that  provided  guiding  principles  for  the  implementation  and  execution 
of  the  roadmap,  were  developed.  These  fundamental  precepts  can  be  considered  as  lessons 
learned  from  the  survey  carried  out  as  part  of  the  initial  work  done  for  the  LVCAR  Study 
[LVCAR-1], 

4.3.1  Fundamental  Precept  #1:  Do  No  Harm 

The  (US)  DoD  should  not  take  any  immediate  action  to  discontinue  any  of  the  existing 
simulation  architectures.  There  is  a  considerable  degree  of  consensus  within  the  LVC  user 
community  that  a  long-term  strategy  based  on  architecture  convergence  would  benefit  the 
DoD.  However,  it  is  also  understood  that  there  are  many  design  issues  that  must  be  resolved 
prior  to  implementing  such  a  strategy,  and  that  the  actual  implementation  needs  to  be  a  well- 
planned,  deliberate,  evolutionary  process  to  avoid  adversely  impacting  participating  user 
communities.  Because  of  these  considerations,  it  would  be  unwise  to  eliminate  support  for 
any  of  the  existing  simulation  architectures  in  the  near-term.  Rather,  as  the  differences  among 
the  architectures  are  gradually  reduced,  it  should  be  the  users  themselves  that  decide  if  and 
when  it  is  appropriate  to  merge  their  architectures  into  some  smaller  set  based  on  both 
technical  and  business  concerns.  Any  attempt  by  the  DoD  to  mandate  a  convergence  solution 
on  an  unwilling  user  base  is  certain  to  meet  strong  resistance  and  likely  to  fail. 

4.3.2  Fundamental  Precept  #2:  Interoperability  is  Not  Free 

The  DoD  must  make  the  necessary  investments  to  enable  implementation  of  the  activities 
described  in  the  LVC  Roadmap.  LVC  interoperability  is  not  free.  It  is  not  reasonable  to  expect 
that  LVC  interoperability  goals  can  be  met  with  little  or  no  investment.  Since  the  return  on 
LVC  investments  is  nearly  impossible  to  accurately  quantify  in  the  near-term,  it  is  understood 
that  major  new  up-front  investments  are  difficult  to  justify.  In  recognition  of  this  fact,  the 
Roadmap  has  taken  a  long-term  approach  which  requires  only  limited  investment  early  in  its 
implementation,  with  subsequent  investments  dependent  on  demonstrable  progress.  Without 
the  necessary  investments,  the  LVC  Roadmap  is  nothing  more  than  a  blueprint  of  what  it  is 
possible  to  accomplish,  with  no  mechanism  to  realise  the  associated  benefits. 

4.3.3  Fundamental  Precept  #3:  Start  with  Small  Steps 

The  DoD  should  take  immediate  action  to  improve  interoperability  among  existing  simulation 
architectures.  The  vast  range  of  technical  problems  currently  associated  with  the  development 
and  execution  of  mixed-architecture  LVC  environments  is  well  recognised.  Such  problems 
increase  the  technical  risk  associated  with  the  use  of  these  mixed-architecture  environments, 
and  require  considerable  resources  to  address.  While  architecture  convergence  would  lessen 
(and  even  eliminate)  several  of  these  problems,  it  is  not  practical  to  expect  any  significant 
degree  of  convergence  to  occur  for  many  years. 

Instead,  LVC  users  need  near-term  solutions  that  reduce  both  cost  and  technical  risk  until 
such  time  as  architecture  convergence  can  occur.  These  solutions  include  actions  such  as 
improved  gateways/ bridges,  common  object  models,  and  common  development/ execution 
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processes.  Many  of  these  solutions  can  be  implemented  at  low  cost,  and  provide  significant 
near-  and  midterm  value  to  the  LVC  community. 

4.3.4  Fundamental  Precept  #4:  Provide  Central  Management 

The  DoD  must  establish  a  centralised  management  structure  that  can  perform  Department¬ 
wide  oversight  of  M&S  resources  and  activities  across  developer  and  user  organisations.  A 
strong  centralised  management  team  is  necessary  to  prevent  further  divergence  and  to 
effectively  enable  the  architecture  convergence  strategy.  This  team  needs  to  have  considerable 
influence  on  the  organisations  that  evolve  the  existing  architectures,  and  must  also  have 
influence  on  funding  decisions  related  to  future  LVC  architecture  development  activities. 
Without  centralised  DoD  management,  existing  architecture  communities  will  continue  to 
operate  in  line  with  their  own  self-interests,  and  the  broader  corporate  needs  of  the  DoD  will 
be  treated  as  secondary  issues  that  are  likely  to  continue  to  be  ignored  as  concerns  that  are  not 
germane  to  the  local  problems. 

4.4  Common  Problems  in  LVC  Events 

The  survey  carried  out  for  the  LVCAR  study  found  that  were  many  common  problems 
encountered  during  the  preparation  for,  and  the  conduct  of,  mixed  architecture  simulation 
events.  While  some  of  the  low-level,  technical  issues  that  needed  to  be  resolved  were  unique 
to  particular  events,  there  was  a  high  degree  of  similarity  in  some  of  the  other  problems  that 
occurred  for  most  events.  Common  problems  occurred  in  the  areas  of  design,  reconciliation, 
and  execution  &  test,  and  some  of  the  problems  impacted  in  all  of  these  areas.  Collectively, 
they  represent  the  areas  that  should  be  addressed  by  activities  designed  to  enhance  the 
interoperability  of  systems  during  mixed  architecture  events. 

4.4.1  Design  Problems 

Design  problems  typically  required  resolution  before  an  integration  event  could  be  conducted. 
The  problems  in  this  group  include: 

•  Different  communities  used  different  systems  engineering  models  and  when 
representatives  of  these  different  communities  had  to  cooperate  to  produce  a  mixed 
architecture  event,  differences  in  process  and  terminology  resulted  in  confusion  and 
delay.  The  different  systems  engineering  processes  had  to  be  correlated  so  that  the 
process  of  designing  the  event  could  proceed; 

•  Because  the  different  architectures  and  protocols  cannot  communicate  directly,  some 
type  of  translation  resource  had  to  be  identified  or  created.  Typically,  many  of  the  same 
kinds  of  resources  (gateways,  bridges,  etc)  had  to  be  constructed  to  support  each 
exercise.  These  resources  are  usually  cost-constrained  to  be  point  solutions  with  little 
effort  expended  to  improve  their  potential  for  reuse; 

•  Systems  that  have  been  built  to  rely  on  and  use  one  architecture  would  not  work  using 
another  architecture  without  non-trivial  modifications.  This  resulted  in  event  designers 
typically  constraining  their  search  for  simulation  systems  that  might  participate  in  the 
event  to  those  that  were  compatible  with  a  specific  architecture,  rather  than  incur  the 
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last-resort  cost  of  mixing  architectures.  In  essence,  the  problem  here  is  that  there  is  no 
real  "plug  and  play"  capability;  and 

•  There  is  some  disparity  in  the  services  provided  by  each  of  the  architectures  (e.g.,  HLA 
provides  time-management  services  while  DIS  does  not).  Typically,  resolving  the 
service  disparity  implies  that  only  those  services  common  to  all  architectures  can  be 
used  across  the  entire  event  -  these  must  be  identified  and  remediation  strategies 
developed,  when  required. 

4.4.2  Reconciliation  Problems 

Reconciliation  problems  are  more  concerned  with  reconciling  differences  between  groups  of 
simulation  systems  than  with  design.  In  some  cases,  they  could  be  encountered  both  prior  to 
and  during  the  integration  event  itself.  The  specific  problems  categorised  here  include: 

•  Typically,  larger  simulation  events  are  designed  to  connect  groups  of  simulations  that 
may  have  been  used  together  in  smaller  events  (e.g.,  a  previously  designed  federation). 
Each  of  these  previously  connected  groups  of  systems  will  have  already  reached 
agreements  between  the  interacting  systems  on  system  responsibilities  and  on  the  types 
of  objects  and  interactions  that  would  be  allowed  (typically  included  in  a  Federation 
Object  Model,  or  FOM,  in  LILA  federations  as  an  example).  The  same  kinds  of 
agreements  must  be  decided  for  the  entire  set  of  systems  that  will  participate  in  the 
larger  event.  Reconciling  the  previously  reached  agreements  can  be  difficult  because 
the  different  architectures  use  their  own  mechanisms  to  express  and  record  the 
agreements.  Essentially,  the  problem  is  that  federation  object  models  must  be 
reconciled  across  the  different  federations  that  will  be  brought  together; 

•  The  different  architectures  have  either  different  standard  object  models  or  no  standard 
object  model.  Object  models  must  be  reconciled  for  both  syntax  and  semantics  and  this 
is  often  more  difficult  than  integrating  the  protocols  themselves;  and 

•  The  different  architectures  (and  different  implementations  of  the  same  architecture) 
have  made  unique,  individual  decisions  concerning  the  specification  of  data  as  it  is 
transmitted  among  participating  systems.  As  a  result,  the  data  encoded  using  the 
conventions  of  one  architecture  cannot  be  decoded  using  the  conventions  of  another 
architecture.  Thus,  the  data  differences  must  be  reconciled  and  represented  in  a 
translator  utility  that  can  be  interposed  between  the  architectures. 

4.4.3  Execute  and  Test  Problems 

The  execute  and  test  problem  category  includes  issues  germane  to  the  run-time  connection 
between  simulation  systems  and  the  testing  that  must  be  applied  to  ensure  data  is  being 
communicated  correctly.  These  issues  include: 

•  Legacy  systems  are  often  included  in  the  larger  events  and  event  designers  are  often 
very  constrained  in  their  ability  to  modify  such  systems.  Thus  these  legacy  systems 
usually  have  to  rely  on  established  communications  capabilities.  Even  when  legacy 
system  modification  is  possible,  it  is  usually  far  more  cost-effective  to  devise  a 
translator  than  to  apply  a  modification; 
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•  In  almost  all  cases,  there  is  no  external  testing  environment  where  systems  can  prepare 
for  the  integration  event  so  that  almost  every  test  has  to  wait  until  the  event  itself. 
LVCAR  workshop  participants  who  have  been  responsible  for  integrating  systems  into 
such  events  note  that:  "There  is  never  enough  integration  test  time  with  a  full  up  and 
running  federation";  and 

•  External  systems  (e.g.,  C4ISR)  that  will  be  connected  to  the  simulation  event  "speak 
their  own  languages"  and,  much  like  the  legacy  systems,  these  languages  can  only  be 
spoken  through  the  use  of  translators. 

Finally,  the  overarching  category  of  problems  included  those  that  spanned  all  three  of  the 
design,  reconciliation,  and  test  &  execution  areas.  These  problems  include: 

•  For  the  most  part,  there  is  very  little  incentive  for  the  different  architectures  to 
interoperate.  Further,  there  is  no  source  of  available  guidance  on  how  they  could 
implement  solutions  in  a  more  standardised  way  that  would  promote  interoperability; 
and 

•  Automated  tools  are  not  often  transferable  between  architectures  as  different  data 
formats  are  involved. 


4.5  Some  Strategies  -  Architectural  Options  or  Courses  of  Action  (CO  A) 

According  to  the  US  LVC  Architecture  Roadmap  (LVCAR)  [LVCAR-2]  many  problems  exist 
with  respect  to  the  procedures  and  technologies  used  to  develop  mixed  architecture  live, 
virtual,  and  constructive  (LVC)  environments.  The  incompatibilities  between  these 
architectures  require  expending  a  considerable  amount  of  resources  to  develop  point  solutions 
that  effectively  integrate  them  into  a  single,  unified  set  of  supporting  simulation  services. 
Gateway  solutions  to  these  types  of  issues  have  frequently  restricted  exercises  to  using  only 
the  limited  set  of  capabilities  that  are  common  across  all  of  the  architectures,  resulting  in  a 
"dumbing  down"  of  the  more  capable  architectures.  Further,  the  lack  of  high-level 
management  oversight  of  all  existing  distributed  simulation  architectures  (as  a  unified 
resource)  has  resulted  in  a  situation  where  continued  divergence  of  architectural  capabilities  is 
not  only  possible  but  likely,  and  new  (potentially  redundant)  architectures  can  emerge  at  any 
time.  Clearly,  such  issues  must  be  satisfactorily  resolved  if  long  term  interoperability  goals  are 
to  be  achieved. 

The  LVCAR  study  considered  five  advanced  distributed  simulation  architectures  that  are  in 
common  use  in  the  US: 

•  Distributed  Interactive  Simulation  (DIS) 

•  Aggregate  Level  Simulation  Protocol  (ALSP) 

•  High  Level  Architecture  (HLA) 

•  Test  and  Training  Enabling  Architecture  (TENA) 

•  Common  Training  and  Instrumentation  Architecture  (CTIA) 
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Each  of  these  architectures  was  designed  to  address  the  requirements  of  its  defined  user  base. 

Figure  3  shows  the  relative  use  of  these  architectures  as  surveyed  by  the  LVCAR  study. 

In  Australia  there  may  be  some  use  of  the  minor  architectures  (mainly  in  Commercial-Off- 
The-Shelf  (COTS)  systems)  however  the  vast  majority  of  distributed  simulation  systems 
would  be  either  DIS  or  HLA. 

LVCAR  Phase  I  efforts  analysed  the  core  requirements  of  each  architecture  and  directly 
compared  key  categories  of  requirements.  There  was  a  high  degree  of  functional  commonality 
between  the  architectures.  However,  there  were  also  some  key  differences,  stemming  from 
specific  needs  that  originally  drove  the  development  of  each  architecture. 

At  the  implementation  level,  there  were  significant  differences  between  architectures  that 
could  potentially  become  barriers  to  achieving  cross  architecture  interoperability.  The  study 
found  that  none  of  these  differences  introduces  irreconcilable  incompatibilities  that  prevent 
the  integration  of  the  different  architectures  into  mixed  architecture  events.  However, 
achieving  such  integration  would  not  be  without  cost,  and  some  degree  of 
analysis /  experimentation  would  be  required  to  determine  the  best  near-,  mid-,  and  long-term 
solutions  to  addressing  these  incompatibilities. 

A  set  of  five  potential  strategies  (Architectural  Options  or  Courses  of  Action  (COA))  were 
identified,  and  a  corresponding  set  of  advantages  and  disadvantages  associated  with  each  of 
these  Courses  of  Action  was  developed.  The  five  potential  Courses  of  Action  are: 


DIS  HLA  TENA  CTIA  ALSP  Other 


Architecture 


Figure  3  Typical  Distribution  of  Architectures  in  Use  in  the  US. 


1.  Status  Quo  or  "Do  Nothing"  -  No  architectural  effort  to  unify  or  enhance  the  existing 
alternatives  will  be  undertaken.  Each  existing  architecture  will  evolve  based  on  its 
own  users'  needs,  and  mixed  architecture  events  will  continue  to  exist  as  currently 
achieved; 
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2.  Actively  Manage  the  Existing  Architectures  -  Create  standard  inter-architecture 
integration  solutions  (effectively  create  an  "architecture  of  architectures").  Keep  the 
current  multiple  architectures  but  invest  in  improving  the  construction  /  performance 
/  integration  of  various  gateways,  translators,  object  models,  and  create  processes  and 
procedures  to  make  inter-architecture  integration  "faster,  easier,  cheaper".  Stand  up 
an  architecture  management  board  (both  policy  and  technical)  to  oversee  all  of  the 
architectures  to  discourage  divergence  and  encourage  compatible  evolution; 

3.  Convergence  -  Each  of  the  existing  architectures  is  evolving,  some  quickly,  some 
slowly.  Create  policy  and  procedures,  and  provide  small  amounts  of  seed  money,  to 
encourage  the  architectures  to  converge  with  one  another  in  X-year  time  frame  (e.g.,  10 
years).  When  they  become  so  similar  in  features  and  capabilities,  engineer  the  merging 
of  them  into  a  single  architecture.  Requires  an  architecture  management  board  (both 
policy  and  technical)  to  oversee  all  of  the  architectures; 

4.  Select  One  of  the  Existing  Architectures  -  Of  the  existing  architectures,  choose  the 
one  that  is  the  most  promising  for  the  long  term  DoD  LVC  community.  Use  policy  and 
funding  to  encourage  development  of  the  chosen  architecture.  Make  improvements 
where  necessary,  discourage  development  of  other  architectures,  and  eventually  get  to 
the  situation  where  the  chosen  architecture  is  dominant;  and 

5.  Develop  A  New  Architecture  -  With  a  better  understanding  of  the  broad  DoD  LVC 
requirements  and  the  manifest  lack  of  any  of  the  current  architectures  to  fully  meet 
them  any  time  in  the  future,  create  a  new  architecture  from  the  best  ideas  of  all  the 
existing  ones,  and  put  the  whole  weight  of  the  Department  behind  it. 

4.6  Remaining  LVCAR  Strategies  After  Some  Elimination 

An  analysis  along  with  an  assessment  of  how  well  each  strategy  met  requirements  derived 
from  assertions  that  characterise  the  current  LVC  interoperability  picture,  led  to  the 
elimination  of  three  strategies  from  further  consideration.  The  remaining  strategies  (Strategies 
2  and  3)  are  defined  as  follows: 

4.6.1  Option  2  -  Enhancing  Interoperability  in  Mixed- Architecture  Environments 

Architectural  Course  of  Action  2:  Define  and  develop  mechanisms  to  improve  (ie  enhance) 
LVC  interoperability  in  mixed  architecture  environments,  assuming  that  the  current 
architectures  will  continue  to  be  used. 

In  this  COA  the  focus  is  to  create  solutions  to  improve  the  interoperation  of  existing 
architectures  in  a  mixed  architecture  environment.  Examples  of  such  solutions  include 
establishing  standard  agreements  (e.g.,  processes,  terminology,  object  models)  that  cut  across 
the  various  architectures,  and  improving  the  performance,  reliability  and  (re)usability  of 
future  gateways  and  bridges.  The  individual  architectures  would  evolve  to  support  their 
native  user  communities,  but  oversight  will  be  provided  to  prevent  divergence  and 
duplication  of  effort.  However,  the  oversight  body  is  advisory  not  regulatory,  and  final 
control  of  the  architecture's  evolution  remains  with  the  "owning"  organisation.  Unlike  the 
approaches  that  focus  on  creating  an  end  state  that  includes  only  a  single  architecture,  this 
COA  assumes  that  there  is  benefit  in  having  multiple  architectures  available  for  use,  that  the 
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benefit  is  worth  the  various  costs  in  maintaining  different  architectures,  and  that  the 
interoperability  problems  inherent  in  mixed-architecture  events  can  be  resolved. 

Primary  advantages  of  this  strategy  are: 

•  User  community  requirements  continue  to  be  met  based  on  the  normal  evolution  of  the 
architectures; 

•  Allows  users  to  choose  from  a  diverse  set  of  architectural  capabilities; 

•  Does  not  impose  a  "one  size  fits  all"  solution; 

•  Actively  improves  interoperability  while  providing  no  disruption  to  existing 
architecture  users; 

•  Multiple  architectures  will  spur  competition  between  providers  and  likely  lead  to  more 
rapid  innovation; 

•  Benefits  can  be  achieved  incrementally;  and 

•  Oversight  Board  provides  a  mechanism  to  arrest  the  continued  development  of  new 
architectures. 

Primary  disadvantages  of  this  strategy  are: 

•  Cross-architecture  integration  will  still  be  required  for  mixed-architecture  events;  and 

•  Funding  will  be  necessary  to  support  potentially  overlapping  architectural  capability. 

This  strategy  is  founded  on  the  idea  that  having  multiple  architectures  available  for  use  is 
desirable  and  that  the  best  way  forward  is  to  take  actions  that  can  reduce  or  eliminate  the 
barriers  to  interoperability  (including  the  specific  problems  described  above)  among  the 
existing  architectures  and  protocols.  More  specifically  this  strategy  acknowledges  that  the 
existing  architectures  have  been  created,  have  evolved,  and  are  being  maintained  to  meet  the 
specific  needs  of  their  constituent  communities.  Elimination  of  any  architecture  should  only 
occur  as  a  natural  result  of  disuse.  Modification  and  management  of  the  existing  architectures 
are  left  to  the  owning  communities  as  the  best  option  to  ensure  meeting  the  needs  of  the 
various  user  communities,  both  throughout  the  DoD  and  among  the  Department's  coalition 
partners.  To  resolve  interoperability  problems,  efforts  should  be  directed  towards  creating 
and  providing  standard  resources,  such  as  common  gateways,  common  componentised  object 
models,  and  common  federation  agreements,  which  can  resolve  the  problems  identified  in  the 
preceding  section  and  render  integration  of  the  multiple  architectures  an  efficient  and  nearly 
transparent  process.  In  effect,  these  actions  will  create  the  perception  of  a  single  architecture 
that  supports  all  the  diverse  simulation  systems,  even  though  the  systems  will  actually  be 
serviced  by  an  "architecture  of  architectures",  comprised  of  as  many  different  architectures 
and  protocols  as  are  required  to  interconnect  the  participating  simulation  systems. 

4.6.2  Option  3  -  Convergence 

Architectural  Course  of  Action  3:  Develop  policy  and  incentives  to  encourage  existing 
architectures  to  converge  (over  some  defined  period  of  time)  to  either  a  single  architecture  or  a 
smaller  set  of  architectures;  ie  encourage  and  facilitate  architecture  convergence. 
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This  COA  3  is  very  similar  to  COA  2,  with  the  exception  that  a  regulatory  oversight  body  will 
implement  policy  actions  and  investment  incentives  (including  disincentives)  to  cause  the 
architectures  to  converge  either  into  a  single  architecture  or  at  least  a  smaller  set  of  compatible 
and  interoperable  architectures.  Thus,  while  the  same  roadmap  actions  could  be  taken  with 
regard  to  improving  both  model  and  runtime  interoperability  in  the  near-  to  mid-term,  this 
COA  will  include  additional  actions  as  necessary  to  achieve  an  appropriate  level  of 
architecture  convergence  (including  potential  physical  convergence)  at  a  specified  future  date. 

Primary  advantages  of  this  strategy  are: 

•  Multiple  architectures  will  compete  to  be  the  "convergence  target",  fostering 
competition  between  providers  and  likely  leading  to  more  rapid  innovation; 

•  Needed  architectural  changes  are  phased-in  to  avoid  user  community  disruptions; 

•  Benefits  can  be  achieved  incrementally;  and 

•  Eliminates  much  of  the  complexity  of  mixed  architecture  environments  in  the  long¬ 
term  if  physical  convergence  can  be  achieved. 

Primary  disadvantages  of  this  strategy  are: 

•  Disruption  to  users,  in  that  the  final  actions  to  achieve  convergence  may  be 
unacceptable  to  existing  architecture  users; 

•  Requires  that  hard  choices  be  made  regarding  several  technical  and  business  model 
issues,  which  may  provide  disincentives  for  affected  users  to  transition;  and 

•  Uncertainty  about  the  degree  of  convergence  that  can  be  achieved  has  potential  for  (ie 
results  in)  failure. 

Strategy  3  (ie  CO  A3),  "Encourage  and  Facilitate  Architecture  Convergence",  is  clearly  related 
to  Strategy  2  (COA2),  but  focuses  on  converging  services  across  the  architectures  as  the 
primary  effort.  This  strategy  rests  on  the  fundamental  cost-avoidance  concept  that  the  current 
set  of  architectures  and  protocols  includes  significant  overlapping  capability  and  that  the 
differences  associated  with  the  implementations  of  these  overlapping  capabilities  should  be 
reduced  whenever  possible. 

In  this  strategy,  the  existing  architectures  will  be  converged  by  modifying  those  architectures 
that  now  provide  similar  services  so  that  they  actually  provide  the  same  service.  Convergence 
could  be  applied  as  an  evolutionary  process  that  could  eventually  result  in  a  smaller  set  of 
more  compatible  architectures.  In  the  limit,  if  full  convergence  could  be  achieved,  all  of  the 
existing  architectures  would  become  so  similar  that  they  would  effectively  become  a  single 
architecture. 

Altering  the  ways  in  which  fundamental  architectural  services  are  provided  to  achieve  a 
common  implementation  across  several  architectures  is  a  technically  demanding  undertaking. 
The  difficulty  of  this  task  should  not  be  underestimated  and  a  significant  amount  of  up-front 
analysis  and  design  needs  to  occur  prior  to  applying  modifications  to  any  of  the  architectures. 
Modifications  should  only  be  applied  when  they  do  not  change  the  fundamental  nature  of  the 
architecture  itself  and  when  the  modifications  can  be  made  in  a  way  consistent  with  the  other 
services  provided  by  that  architecture. 


UNCLASSIFIED 


25 


UNCLASSIFIED 


DSTO-GD-0645 

However,  the  process  of  convergence  will  necessarily  take  place  over  an  extended  period  of 
time.  Because  the  LVC  interoperability  problem  is  immediate.  Strategy  3  also  includes  the 
near-term  actions  that  form  the  basis  of  Strategy  2.  That  is,  the  same  set  of  actions  required  to 
reduce  or  eliminate  the  architecture-integration  effort  for  mixed-architecture  events  are  also 
required  in  Strategy  3  to  enable  convergence. 


4.7  The  Way  Ahead 

Summing  up.  Option  2  is  based  on  the  assumption  that  the  current  state  of  multiple, 
somewhat  overlapping,  architectural  capabilities  is  useful  and  seeks  to  take  actions  that  will 
make  integrating  these  existing  architectures  easier,  without  forcing  modifications  of  the 
architectures  themselves.  Option  3  recognises  the  immediate  need  for  creating  the  same  set  of 
resources  to  achieve  interoperability,  but  characterises  those  resources  as  interim  measures 
that  should  eventually  become  less  necessary  as  the  existing  architectures  converge  into  a 
smaller,  more  compatible  and  easily  integrated  set.  Thus,  the  near  term  requirements  for 
enhancing  the  current  interoperability  picture  look  very  similar,  regardless  of  the  ultimate 
strategy. 

The  near-  to  mid-term  activities  that  could  occur  as  parts  of  either  strategy  cover  a  wide  range. 
Some  are  useful  only  within  the  context  of  attempting  to  achieve  architectural  convergence. 
Others  involve  resources  that  will  reduce  the  effort  required  to  achieve  integration  required  as 
part  of  creating  mixed  architecture  simulation  events.  Others  are  useful  in  either  undertaking. 
These  actions  and  activities  include  feasibility  studies,  planning  efforts,  implementation 
efforts,  and  capabilities  analyses.  Ultimately,  the  selected  set  of  activities  will  constitute  the 
recommended  course  of  action  in  the  LVCAR  Roadmap.  The  interoperability  enhancing 
activities  that  have  been  identified  include: 

•  Devise  the  common  components  of  architecture-independent  object  models; 

•  Produce  common  gateways  and  bridges; 

•  Create  a  common,  reusable  federation  agreement  template; 

•  Provide  an  analysis  of  the  processes  and  infrastructure  supporting  M&S  asset  reuse; 

•  Describe  and  document  a  common,  architecture-independent  systems  engineering 
process; 

•  Produce  and  /  or  enable  reusable  development  tools; 

•  Implement  a  process  to  maintain  specifications  for  current  and  future  requirements; 

•  Specify  a  resource  to  facilitate  pre-integration  systems  readiness;  and 

•  Determine  the  feasibility  of  a  common  wire-level  protocol. 

The  following  sections  describe  each  of  these  potential  activities  in  more  detail.  Relationships 
(potential  dependencies)  between  them  are  also  presented.  These  relationships  are  used  to 
create  a  sequence  of  actions  that  could  be  viewed  as  an  initial  roadmap  of  activities  that  will 
improve  the  current  state  of  LVC  interoperability. 
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4.7.1  Common  Components  of  Architecture-Independent  Object  Models 

Reconciling  the  differences  between  the  various  formats  and  content  of  the  object  models  used 
in  different  M&S  user  communities  has  been  recognised  as  a  source  of  excessive  resource 
consumption  when  building  mixed  architecture  environments.  Providing  a  common  object 
model,  comprised  of  common  components  (object  model  building  blocks,  sometimes  referred 
to  as  base  object  models)  and  including  mappings  to  current  architecture  object  models, 
would  allow  mixed  architecture  integration  to  proceed  faster  and  easier. 

4.7.2  Produce  Common  Gateways  and  Bridges 

According  to  the  LVCAR  study  gateways  are  the  most  widely  used  method  to  link  disparate 
simulations  together.  Gateways  have  demonstrated  an  impressive  range  of  capabilities  across 
the  simulation  communities  that  employ  them,  such  as  the  ability  to  translate  between 
different  protocols  or  object  model  representations  and  to  address  disparities  in  the  services 
typically  encountered  in  mixed  architecture  environments  (e.g.,  time  management,  filtering, 
etc.).  However,  most  gateways  are  designed  as  point  solutions  for  specific  problems,  and  are 
rarely  shared  across  user  organisations.  Thus,  the  same  basic  capabilities  tend  to  get 
developed  multiple  times,  and  programs  may  not  even  know  about  more  advanced  features 
developed  by  other  organisations. 

The  adoption  of  common  object  models  would  reduce  the  complexity  and  individuality  of 
gateways  required,  eventually  leading  to  a  standard  set  of  gateways  and  bridges  along  with 
supporting  user  and  developer  documentation.  Possible  "missing  services"  could  be 
incorporated  within  the  gateways  and  such  common  inter-architecture  translator  gateways 
would  become  readily  available  assets  thereby  relieving  individual  programs  and 
organisations  of  the  need  to  develop  their  own  gateways  with  specific  capabilities. 

4.7.3  Create  a  Common,  Reusable  Federation  Agreement  Template 

According  to  the  LVCAR  study  many  of  the  issues  that  arise  when  developing  distributed 
simulation  environments  require  the  establishment  of  agreements  among  all  federation 
participants  as  a  precursor  to  resolution.  Currently,  there  is  no  architecture  independent 
standard  format  or  content  for  Federation  Agreements  documents.  Thus,  programs  must 
continuously  rediscover  what  types  of  information  require  cross-federation  agreements,  and 
the  lack  of  a  standard  format  adversely  affects  the  reusability  of  these  products. 

The  purpose  of  this  task  is  to  develop  an  architecture-independent  template  for  establishing 
Federation  Agreements,  along  with  potential  architecture-specific  extensions.  This  activity  is 
primarily  designed  to  address  problems  that  arise  due  to  differences  between  Federation 
Object  Models  (FOM).  While  the  activity  is  not  designed  to  produce  a  standard  FOM,  it 
should  produce  a  standardised  template  that  would  permit  the  FOM  reconciliation  task  to 
proceed  much  more  easily.  The  product  of  this  effort  will  be  an  architecture-independent 
template  for  establishing  Federation  Agreements,  along  with  potential  architecture-specific 
extensions. 


UNCLASSIFIED 


27 


UNCLASSIFIED 

DSTO-GD-0645 

4.7.4  Describe  and  Document  a  Common,  Architecture-Independent  Systems 
Engineering  Process 

When  the  user  communities  of  different  architectures  are  brought  together  to  develop  a  single 
mixed  architecture  distributed  simulation  environment,  the  differences  in  the  development 
processes  native  to  each  user  community  represent  a  persistent  barrier  to  effective 
collaboration.  That  is,  since  these  communities  must  work  together  toward  a  common  goal, 
differences  in  the  practices  and  procedures  these  communities  typically  use  to  build  new 
simulation  environments  can  lead  to  misunderstandings,  misinterpretations,  and  general 
confusion.  This  introduces  risk  from  both  the  technical  and  schedule  perspectives. 

A  common  systems  engineering  process  model  needs  to  be  developed  for  all  users  of 
distributed  simulation.  Existing  architecture-specific  process  models  (DIS  -  IEEE  1278.3  - 
Exercise  Management  and  Feedback  -  Recommended  Practice,  FILA  -  IEEE  1516.3  Federation 
Development  and  Execution  Process  (FEDEP)  -  Recommended  Practice,  TENA  ConOps,  etc) 
will  be  examined  to  identify  the  key  similarities  and  differences,  and  a  consensus-building 
process  will  be  instantiated  to  develop  the  required  product.  The  product  from  this  activity 
will  be  a  common  systems  engineering  process  model  that  can  be  applied  across  the  full  range 
of  DoD  distributed  simulation  users.  Specific  implementation  guidance  that  describes  how  the 
common  process  model  should  be  tailored  to  meet  the  needs  of  specific  architecture  users  will 
also  be  included  as  part  of  this  activity.  Finally,  an  Architecture  User  Guide  will  be  included 
as  an  annex  to  the  core  document.  This  guide  would  define  a  mapping  between  the  type  of 
simulation  event  and  the  architecture  or  protocol  that  offers  best  support  for  that  purpose. 

4.7.5  Common  Tools 

Some  examples  of  common  tools  that  could  be  used  by  any  or  all  participating  LVC  systems 
include  requirements  development  tools,  scenario  development  tools,  conceptual  and  object 
modelling  tools,  design  tools,  networking  tools,  testing  tools.  After  Action  Review  (AAR) 
tools,  etc.  Many  such  tools  would  already  be  in  use  in  DSTO  and  each  tool  would  have  a 
corresponding  business  model  such  as  COTS,  GOTS,  and  proprietary  (DSTO  developed) 
solutions.  The  various  business  model  options  associated  with  each  tool  may  be  a  significant 
impediment  to  sharing  these  tools  across  the  ADF. 

Another  potential  barrier  to  reuse  of  tools  is  that  there  are  many  different  formats  used  by  the 
different  architectures  to  store  exercise  data.  Different  data  storage  formats  used  across  the 
various  architectures  should  be  examined  to  determine  the  feasibility  of  using  a  set  of 
architecture-independent  formats  for  storage  of  classes  of  data. 

A  library  of  cross-community  reusable  tools  for  LVC  environment  development,  along  with  a 
business  model  for  tool  distribution  should  be  created  and  a  set  of  architecture-independent 
data  storage  formats,  specified  according  to  type  of  data  and  allowing  the  tools  to  operate  in 
different  architecture  environments,  should  be  investigated. 

4.7.6  Specify  a  Capability  to  Facilitate  Pre-integration  Systems  Readiness 

Simulation  system  integration  into  large  simulation  events  can  be  a  very  lengthy  process  of 
error  detection  and  remediation.  This  problem  could  be  reduced  if  individual  or  small 
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numbers  of  simulation  systems  could  be  more  fully  tested  for  integration  readiness  prior  to 
integration  into  the  actual  exercise  event. 

A  test  integration  capability  should  be  developed  including  such  capabilities  as  establishing 
reusable  simulation  exercises  that  include  multiple  systems  using  all  of  the  architectures  that 
are  currently  used  in  DoD  events.  Such  a  resource  should  be  developed  to  allow  join  and 
resign  actions  by  individual  simulation  systems  over  existing  networks.  The  joining  systems 
(e.g.,  the  systems  under  test)  would  be  required  to  originate  and  receive  interactions  to  and 
from  simulation  systems  residing  on  a  variety  of  architectures.  Such  a  capability  would  reduce 
the  time  required  to  complete  the  integration  cycle,  thus  addressing  a  problem  in  the  execute 
and  test  problem  group. 

This  approach  is  the  basis  of  the  standards-based  methodology  used  by  the  USAF  DMO 
program  whereby  a  LVC  system  cannot  connect  and  interoperate  on  the  DMO  Network  (ie 
join  and  participate  in  a  DMO  exercise)  unless  it  has  been  tested  and  found  to  be  compliant 
with  USAF  DMO  interoperability  standards  [Aldinger],  [Zalcman  (2010)] 

4.7.7  Determine  the  Feasibility  of  a  Common  Wire-Level  Protocol  and  a  Common  API 

For  those  architectures  that  include  an  API  standard,  the  wire  protocol  for 
intercommunication  with  other  simulations  is  embodied  in  the  middleware,  and  thus  is 
completely  opaque  to  most  users.  However,  if  the  wire  protocols  used  by  different 
middleware  applications  are  different,  it  is  impossible  for  the  middleware  applications  to 
interoperate  at  runtime  unless  appropriate  bridges  or  gateways  are  put  into  place.  This  is  the 
case  for  HLA  [Tudor],  These  translation  utilities  represent  a  potential  source  of  error,  consume 
valuable  program  resources  to  develop  and  integrate,  and  add  complexity  to  the  architecture 
of  the  M&S  environment. 

Whether  a  "common  API"  is  feasible  should  also  be  determined.  That  is,  there  could  be  a 
higher-level  API,  with  its  own  specification  of  function  calls  that  could  ultimately  be 
translated  into  the  calls  defined  in  either  the  TENA  or  HLA  API.  Use  of  such  an  API,  in  a 
simulation  application,  would  permit  compilation  to  either  of  the  target  architectures  (HLA  or 
TENA). 

The  COTS  MaK  Technologies  VR-Link  toolkit  adopts  this  approach  in  that  a  common,  higher- 
level  API  provides  support  for  DIS,  HLA  1.3,  HLA  1516,  and  TENA  [MaK].  Presumably  VR- 
Link  will  be  upgraded  to  provide  support  for  HLA  Evolved  also. 

This  common  API  approach  should  also  be  considered  for  DSTO  (AOD  and  Net  Warrior) 
support  of  the  Link-16  tactical  data  link  protocol.  In  DSTO's  Air  Operations  Division  the 
Airborne  Systems  Connectivity  Environment  Laboratory  (ASCEL)  supports  Link-16 
interoperability  using  the  Rockwell  Collins  Rosetta  toolkit  [Filippidis];  the  DSTO  developed 
ADGESIM  system  supports  Link-16  interoperability  using  the  TCG  Link-PRO  toolkit 
[Zalcman  (2009)-l],  [Zalcman  (2009)-2];  and  the  Air  Operations  Simulation  Centre  is 
developing  its  own  proprietary  toolkit  to  support  Link-16  interoperability.  A  common  API 
system  should  be  developed  to  provide  higher-level  support  for  all  these  Link-16  toolkits. 

The  LVCAR  Study  recommends  that  the  feasibility  of  developing  a  common  wire  protocol 
across  different  architectures  and  a  common  (higher-level)  API  should  be  investigated.  In  the 
case  of  HLA,  it  would  also  involve  determining  the  feasibility  of  a  common  wire  protocol  and 
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API  for  different  versions  of  the  RTI  (e.g.,  RTI-S,  HLA  1.3  RTIs  and  HLA  1516  RTIs  (HLA- 
Evolved?)).  The  activity  would  include  an  examination  of  the  different  wire  protocols  and 
APIs  in  use  today,  and  identifying  and  resolving  the  various  technical,  business,  and 
standards  issues  involved  with  achieving  the  necessary  consensus  agreements  across  the 
various  architecture  developers.  Note  that,  in  addition  to  feasibility,  this  effort  should  also 
address  some  of  the  desirability  aspects  of  the  problem.  That  is,  it  may  be  that  both  a  common 
wire  protocol  and  API  are  technically  feasible  and  could  be  implemented  from  both  a  business 
and  standards  sense,  but  it  still  may  not  be  desirable  to  pursue  either  one,  either  for  cultural 
reasons  or  for  reasons  related  to  the  potential  impact  on  commercial  developers. 

If  possible  a  common  wire-level  protocol  would  facilitate  the  development  of  common, 
reusable  tools  and  utilities,  and  the  development  of  a  pre-integration  readiness  capability.  The 
availability  of  either  a  common  wire  protocol  or  a  common  API  would  simplify  the  problem 
of  creating  common  gateways  and  bridges. 

4.7.8  Enabling  Interoperability  Now  and  Architecture  Convergence  in  the  Future 

The  activities  described  in  this  current  section  will  improve  interoperability  in  mixed 
architecture  events  as  soon  as  the  associated  resources  can  be  made  available.  Some  of  these 
activities  lead  directly  to  converged  architectural  capabilities,  primarily  regarding  HLA, 
TENA,  and  CTIA.  According  to  the  LVCAR  study: 

"It  is  much  less  desirable  to  seek  a  high  degree  of  convergence  for  DIS  because  adding  the 
necessary  services  to  that  protocol  would  effectively  undermine  the  advantage  it  now 
enjoys;  it  currently  provides  the  essential  intercommunication  services  without  adding 
excessive  user  burdens  or  complexity." 

4.7.9  Model  Consistency 

Incompatibilities  in  the  way  real  operations  are  represented  in  different  simulations  can 
significantly  affect  the  validity  of  simulation  interactions.  "Fair  fight"  issues  can  sometimes 
occur  simply  due  to  the  underlying  algorithms  the  various  simulations  use  to  model  real 
world  phenomena.  For  instance,  if  two  simulations  within  a  distributed  simulation 
environment  are  representing  the  exact  same  radar  (with  exactly  the  same  system  data)  but 
use  different  algorithms  for  modelling  detection  and  tracking  performance,  it  is  quite  possible 
for  different  instantiations  of  the  same  radar  to  perform  differently.  Obviously,  such 
artificialities  would  not  occur  in  the  real  world,  and  thus  the  validity  of  the  simulation  results 
would  be  compromised. 

The  need  in  this  area  is  to  examine  the  algorithms  currently  used  to  model  real  world  systems 
and  phenomena  of  military  interest,  and  determine  if  agreements  can  be  achieved  across  user 
communities  on  standards  for  common  algorithms.  The  scope  should  be  based  on  an 
assessment  of  which  algorithms  are  most  common  across  DoD  simulations  and  where 
agreements  across  user  communities  are  most  feasible. 

In  addition  to  standardisation  of  algorithms,  it  is  desired  that  implementations  of  those 
standards  be  made  available  for  general  reuse  in  the  M&S  community.  Therefore  there  is  also 
a  need  to  address  the  use  of  repositories  for  reusable  M&S  software  distribution,  as  well  as  the 
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business  and  cultural  issues  and  associated  incentives  required  to  facilitate  widespread 
sharing  of  models  across  programs  and  whole  communities. 

4.7.10  Environmental  Representations 

There  has  been  a  considerable  amount  of  work  across  the  Services  and  various  DoD  agencies 
to  reduce  the  amount  of  effort  required  to  develop  and  share  environmental  data  for  use 
within  DoD  simulation  events.  Examples  include  the  SEDRIS  standard  for  environmental  data 
interchange  and  the  Environment  Scenario  Generator  (ESG)  for  production  of  environmental 
databases.  However,  ensuring  that  use  of  different  simulated  environments  can  result  in  valid 
system-to-system  interactions  remains  a  persistent  problem  in  distributed  simulation  events. 
The  notion  of  "correlating  environment  representations"  permeates  the  community,  without  a 
common  understanding  of  the  processes  necessary  to  achieve  fully  interoperable  simulated 
environments.  Thus,  there  are  needs  to  craft  a  procedural  definition  of  environmental 
correlation,  identify  the  main  barriers  to  implementing  a  complete,  consistent  environmental 
representation  management  strategy,  and  identify  effective  implementation  policies.  Missing 
resources  include  a  technical  strategy  and  implementation  approach  for  improving  the 
representation  of  the  environment  in  LVC  environments.  The  implementation  approach 
should  address  tool  requirements  and  business  model  considerations. 

4.7.11  Human  Behavior  Modelling 

The  sheer  size  of  modern  battlespaces  dictates  the  need  for  Constructive  (such  as  Semi- 
Automated  Forces  (SAFs),  Computer  Generated  Forces  (CGFs),  etc)  applications  to  simulate 
human  behaviors.  That  is,  there  are  so  many  human  participants  in  simulations  of  current  and 
predicted  military  engagements  that  having  live  operators  for  all  decision-making  entities  is 
just  not  possible.  Many  live  training  events  use  SAF  for  opposing  forces,  but  many  also  use 
SAF  for  friendly  forces  they  must  cooperate  with  to  achieve  identified  objectives.  While 
considerable  research  has  gone  into  this  area  the  requirement  for  realistic  and  consistent  SAF 
representations  across  the  full  range  of  entities  that  play  in  modern  warfare  representations  is 
still  largely  unmet. 

The  need  in  this  area  is  to  examine  the  current  state  of  human  behavior  modeling  within  the 
DoD,  identify  gaps,  and  develop  potential  solutions  that  not  only  meet  gaps  in  functionality, 
but  also  address  functional  inconsistencies  that  can  occur  in  mixed  architecture  environments. 
The  strategy  here  should  emphasise  the  standardisation  and  sharing  of  existing  capabilities 
(e.g.,  JSAF,  OneSAF)  rather  than  performing  new  research.  Mechanisms  to  extract  such 
capabilities  from  specific  M&S  systems  so  that  they  can  be  reused  in  other  M&S  systems  must 
be  emphasised  whenever  feasible. 

4.7.12  Bridging  Multiple  Security  Domains 

Issues  of  security  are  extremely  important  when  conducting  a  distributed  LVC  simulation 
event.  When  the  entire  event  is  conducted  at  a  single  level  of  security,  the  mechanisms  to 
ensure  that  security  policies  and  procedures  are  being  fully  addressed  are  generally  well 
understood.  However,  many  distributed  events  involve  the  integration  of  "enclaves"  of  LVC 
systems  that  operate  at  different  levels  of  classification.  Current  mechanisms  to  bridge  across 
different  security  levels  are  very  expensive  and  time  consuming  to  implement,  and  verifying 
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that  the  guards  are  operating  correctly  (as  part  of  overall  LVC  environment  testing)  is  often 
unacceptably  resource  intensive. 

The  need  in  this  area  is  to  examine  the  issues  related  to  bridging  multiple  security  domains, 
based  on  user  requirements.  Policies,  methodologies,  and  technologies  must  all  be  considered 
in  deriving  an  optimal  overall  solution  for  future  users  of  LVC  environments. 


4.8  LVCAR  Study  Conclusions  and  Recommendations 

4.8.1  Technical  Area  Conclusions 

Each  of  the  existing  architectures  provides  useful  service  to  a  dedicated  user  community. 
While  there  are  many  similarities  between  these  architectures,  there  are  also  differences 
(largely  apart  from  technical  capabilities,  but  including  important  cultural  and  business  model 
factors)  so  that  each  architecture  has  an  appropriate  role  within  the  entire  community.  The 
similarities  among  the  architectures  are  based  on  technical  service  capabilities  and  these 
similarities  could  be  exploited  and  increased  to  lessen  the  problems  encountered  during 
mixed-architecture  integration  efforts.  One  way  to  enhance  the  similarities  among  the 
architectures  is  through  a  process  of  managed  capability  convergence,  intentionally  modifying 
selected  services,  by  architecture,  to  create  commonality.  DIS  only  presents  limited 
opportunities  for  convergence  (section  4.7.8).  Higher  levels  of  convergence  are  feasible  for 
HLA,  TENA,  and  CTIA.  Apart  from  convergence,  there  are  also  opportunities  to  improve 
mixed  architecture  interoperability  by  creating  commonly  used  resources  (external  to  any  of 
the  architectures)  such  as  gateways,  common  object  model  components,  and  other  resources 
already  described  above.  In  short,  where  the  architectural  resources  available  to  the 
Department  (US  DoD)  are  providing  a  high  level  of  service,  full  replacement  is  not  necessary. 
The  priority  need  is  to  make  the  available  architectures  capable  of  easily  working  together  and 
this  can  be  done  by  exploiting  opportunities  to  converge  services  and  by  providing 
interoperability-enhancing  resources. 

There  is  also  a  need  to  stop  the  further  creation  of  alternate  architectures.  There  is  no  evidence 
that  current  or  future  requirements  cannot  be  met  by  the  available  resources,  either  as  they 
stand  today  or  after  some  level  of  enhancement.  Further,  enhancing  one  or  more  of  the 
available  architectures  to  meet  unresolved  needs  is  preferable  to  creating  "new  and 
improved"  alternate  architectures,  not  only  from  a  cost  basis,  but  from  an  interoperability 
perspective  as  well.  One  lesson  of  history  is  that,  if  a  new  architecture  is  created  to  replace  one 
or  more  of  the  existing  set,  the  most  likely  outcome  is  that  there  will  simply  be  one  more 
architecture  added  to  the  available  set.  Also  retiring  an  architecture  has  proven  very  difficult. 

4.8.2  Technical  Area  Recommendations 

1.  All  of  the  existing  architectures  should  continue  to  receive  support  in  the  immediate 
future.  Subsequent  to  the  conclusion  of  the  convergence  service  area  feasibility 
experiments,  one  or  more  of  the  architectures  may  be  subsumed  by  a  converged 
capability,  providing  a  rational  basis  for  ending  US  DoD  support  to  the  subsumed 
architecture  (s). 
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2.  DIS  should  only  be  considered  as  a  candidate  for  limited  convergence.  This  protocol 
provides  unique  services  and  capabilities  that  would  be  lost  were  the  protocol  to  be 
fully  converged  with  other  architectures  that  serve  different  communities  and 
necessarily  provide  higher  levels  of  service  capability.  While  some  of  the  activities  that 
could  lead  to  more  service-level  compatibility  (e.g.,  common,  components  of  object 
models,  standard  wire-level  protocols,  etc.)  between  DIS  and  the  other  architectures 
will  prove  advantageous,  DIS  should  remain  much  as  it  is  today,  a  lightweight,  core 
capability  protocol. 

3.  From  a  technical  point  of  view,  there  are  significant  opportunities  to  converge  the 
services  provided  by  FILA,  TENA,  and  CTIA.  A  follow-on  effort  to  conduct  additional, 
more  detailed  analyses  and  experiments  should  be  chartered.  This  effort  should  be 
focused  on  producing  qualitative  data  that  can  lead  to  informed  decisions  on  specific 
service  capabilities  to  be  converged.  Whether  or  not  such  service-level  convergence 
leads  to  eventual  architecture  convergence,  achieving  a  state  where  these  architectures 
provide  very  similar  services  will  facilitate  interoperability  and  decrease  the 
integration  effort  when  conducting  mixed-architecture  events. 

4.  The  creation  of  a  common,  component-based  object  model  should  be  aggressively 
pursued.  The  Department  should  leverage  existing  efforts  in  this  area  now  underway 
at  JFCOM  and  ensure  that  the  result  spans  joint  needs  across  the  entire  Department. 

5.  The  creation  of  shared  and  reusable  intercommunication  mechanisms  (e.g.,  gateways 
and  bridges)  should  be  aggressively  pursued.  A  follow-on  effort  to  produce  the 
technology  required  in  this  area,  to  include  specification  of  suitable  discovery  and 
distribution  mechanisms  should  begin  as  soon  as  supporting  resources  can  be  made 
available. 


4.9  Section  Summary 

The  Live-Virtual-Constructive  Architecture  Roadmap  (LVCAR)  is  intended  to  guide  actions 
and  decision-making  on  the  development,  employment  and  integration  of  US  DoD  LVC 
environments  and  architectures  over  the  next  10  years. 

The  purpose  of  the  LVCAR  Study  (phase  1  of  the  LVCAR)  was  to  develop  a  future  vision  and 
supporting  strategy  to  achieve  significant  interoperability  improvements  in  LVC  simulation 
environments. 

To  support  the  implementation  of  this  strategy  the  LVCAR  study  specifies  near-,  mid-,  and 
long-term  actions  that  collectively  delineate  a  roadmap  that  begins  to  guide  the  evolution 
from  the  current  state  of  LVC  environment  development  to  achieve  the  desired  future  vision. 
However  in  such  a  complex  environment,  mid-course  adjustments  would  be  expected. 

The  presence  of  multiple  protocols/  architectures  and  the  (incorrect)  perception  that 
interoperability  would  be  much  easier  (and  less  costly)  if  only  a  single  architecture  were 
available  has  been  discussed. 

The  LVCAR  Study  developed  four  core  principles  (fundamental  precepts)  which  were: 
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•  Do  No  Harm  -  The  (US)  DoD  should  not  take  any  immediate  action  to  discontinue  any 
of  the  existing  simulation  architectures.  Rather,  as  the  differences  among  the 
architectures  are  gradually  reduced,  the  users  themselves  should  decide  if  and  when  it 
is  appropriate  to  merge  their  architectures  into  some  smaller  set  based  on  both  technical 
and  business  concerns.  Any  attempt  by  the  DoD  to  mandate  a  convergence  solution  on 
an  unwilling  user  base  is  certain  to  meet  strong  resistance  and  would  be  likely  to  fail. 

•  LVC  Interoperability  is  not  free  -  The  DoD  must  invest  resources  to  enable  the 
activities  described  in  the  LVC  Roadmap.  However  the  Roadmap  recommends  a  long¬ 
term  approach  which  requires  only  limited  investment  early  in  its  implementation, 
with  subsequent  investments  dependent  on  demonstrable  progress.  Without  the 
necessary  investments,  the  LVC  Roadmap  is  nothing  more  than  a  blueprint  of  what  it  is 
possible  to  accomplish,  with  no  mechanism  to  realise  the  associated  benefits. 

•  Start  with  Small  Steps  -  The  DoD  should  take  immediate  action  to  improve 
interoperability  among  simulation  architectures.  LVC  users  need  near-term  solutions 
(improved  gateways/  bridges,  common  object  models,  and  common 
development/ execution  processes)  that  reduce  both  cost  and  technical  risk  until 
architecture  convergence  (many  years)  can  occur.  These  solutions  may  be  low  cost,  and 
provide  significant  near-  and  mid-term  value  to  the  LVC  community. 

•  Provide  Central  Management  -  The  DoD  must  establish  a  centralised  management 
structure  that  can  perform  wide  oversight  of  M&S  resources  and  activities  across 
developer  and  user  organisations  to  prevent  divergence  and  enable  the  architecture 
convergence  strategy.  This  team  needs  to  have  considerable  influence  on  funding 
decisions  related  to  future  LVC  architecture  development  activities.  Otherwise  existing 
architecture  communities  will  continue  to  treat  DoD  requirements  as  secondary  issues 
that  are  likely  to  be  ignored  as  concerns  that  are  not  germane  to  the  local  problems. 

A  set  of  five  potential  strategies  were  identified  and  investigated: 

•  Status  Quo  or  "Do  Nothing"; 

•  Actively  Manage  the  Existing  Architectures; 

•  Convergence; 

•  Select  One  of  the  Existing  Architectures;  and 

•  Develop  A  New  Architecture. 

Two  strategies  (Courses  of  Action  (COA))  were  recommended: 

•  Actively  Manage  the  Existing  Architectures  -  Create  standard  inter-architecture 
integration  solutions.  Keep  the  current  multiple  architectures  but  invest  in  improving 
the  construction  /  performance  /  integration  of  various  gateways,  translators,  object 
models,  and  create  processes  and  procedures  to  make  inter-architecture  integration 
"faster,  easier,  cheaper";  and 

•  Convergence  -  Create  policy  and  procedures,  and  provide  small  amounts  of  seed 
money,  to  encourage  the  architectures  to  converge  with  one  another  in  the  long  term 
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time  frame  (e.g.,  10  years).  When  they  become  so  similar  in  features  and  capabilities, 
engineer  the  merging  of  them  into  a  single  architecture. 

The  interoperability-enhancing  set  of  activities  that  will  result  in  a  recommended  course  of 
action  were  identified  and  include: 

•  Devise  the  common  components  of  architecture-independent  object  models; 

•  Produce  common  gateways  and  bridges; 

•  Create  a  common,  reusable  federation  agreement  template; 

•  Describe  and  document  a  common,  architecture-independent  systems  engineering 
process; 

•  Develop  and  /  or  use  reusable  common  tools; 

•  Implement  a  process  to  maintain  specifications  for  current  and  future  requirements; 
and 

•  Facilitate  pre-integration  systems  readiness. 

5.  How  is  the  US  DOD  LVCAR  Study  Relevant  to  the 

ADF? 


The  LVCAR  Study  was  carried  out  by  the  US  DoD  and  is  applicable  to  the  US  LVC 
environment.  The  Net  Warrior  initiative  is  DSTO  only;  however  it  should  be  indicative  of  the 
LVC  environment  in  the  ADF. 

Comparing  the  situation  found  in  Net  Warrior  in  DSTO  with  what  was  found  in  the  LVCAR 
Study  in  the  US  may  give  valuable  insights  into  the  ADF  LVC  environment  in  Australia  -  that 
is,  are  the  LVCAR  Study  strategies,  precepts,  assumptions,  etc.  useful  and  relevant  to  the 
ADF? 

5.1  The  DSTO  (AOD)  Net  Warrior  Initiative 

The  DSTO  Net  Warrior  initiative  was  conceived  to  address,  through  experimentation,  new 
and  evolving  network  centric  capabilities  and  mission  system  technologies  to  enhance  ADF 
joint  war  fighting  capabilities  [Foster],  [Sioutis] .  With  this  as  the  prime  objective.  Net  Warrior 
will  be  in  part  the  realisation  of  a  general  ambition  in  DSTO  to  create  a  research  network  of 
(NCW  enabled)  Battlelabs  [Filippidis], 

Initially,  the  Net  Warrior  initiative  developed  a  persistent  network  infrastructure  to  support  a 
research  capability  in  NCW  by  connecting  a  set  of  nodes  which  are  test-beds  representing 
current  or  potential  future  ADF  assets  [Lawrie],  [Zalcman  (2006)],  [Zalcman  (2007)],  [Zalcman 
(2008)].  The  nodes  were  selected  using  the  criteria  of: 

•  The  need  for  interoperability  of  the  real  assets; 
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•  The  significance  of  the  real  assets  in  joint  operations; 

•  Whether  high  fidelity  representations  of  the  assets  exist  or  are  planned  in  DSTO;  and 

•  Whether  experimental  representations  of  potential  assets  would  benefit  from 
participating. 

The  DSTO  nodes  will  be  high  fidelity  representations  of  airborne  and  maritime  assets  and  will 
include  AEW&C  (Airborne  Early  Warning  &  Control),  an  Air  Defence  Ground  System 
(ADGE)  and  a  future  ship.  Higher  fidelity  test-beds  will  allow  evaluation  of  real  systems  and 
investigation  of  technical  issues. 

These  nodes  already  exist  in  some  form,  but  at  present  are  not  able  to  interoperate 
appropriately.  The  test-beds  will  evolve  in  themselves  as  integral  components  of  the  Net 
Warrior  network  and  as  stand-alone  components  of  research  capabilities  with  platform  centric 
research  objectives.  Where  there  is  common  interest,  exercises  will  be  run  that  involve  all 
nodes  or  a  subset  of  these  nodes. 

An  objective  of  Net  Warrior  is  to  support  coalition  (eg  DMO)  interoperability  however  there 
currently  are  no  existing  Net  Warrior  interoperability  standards  (ie  a  Net  Warrior  Synthetic 
Range  Interoperability  Model). 

The  development  of  such  a  set  of  coalition  compliant.  Net  Warrior  interoperability  standards 
will  accelerate  the  development  of  coalition  compliant  interoperability  for  individual  Net 
Warrior  systems  since  it  is  assumed  that  the  (Net  Warrior)  Synthetic  Range  Interoperability 
Model  used  will  define  a  set  of  (distributed  simulation,  radio  communications  and  tactical 
data  link)  interoperability  standards  that  should  be  very  similar  to  the  interoperability 
standards  used  by  coalition  partners  such  as  the  USAF  DMO  Program.  Therefore  ADF  LVC 
systems  (eg  Net  Warrior  LVC  systems)  that  are  compliant  with  the  recommended  ADF 
Corporate  Synthetic  Range  Interoperability  Model  should  then  also  be  highly  interoperable 
with  coalition  LVC  systems  such  as  USAF  DMO  compliant,  LVC  systems. 


5.2  What  Advanced  Distributed  Simulation  Protocols  Need  To  Be 
Supported? 

Figure  3  shows  that  the  US  has  to  deal  with  at  least  five  Advanced  Distributed  Simulation 
protocols/  architectures  (HLA,  DIS,  TENA,  ALSP,  CTIA  etc.)  where  DIS  and  HLA  each 
account  for  approximately  35%  of  the  systems  surveyed  in  the  LVCAR  Study. 

In  Australia  most  simulation  systems  with  external  interoperability  will  be  either  DIS  or  HLA. 
This  is  extremely  convenient  as  any  discussion  as  far  as  the  ADF  is  concerned  can  be  limited 
(has  already  converged)  to  just  DIS  and  HLA. 

Only  having  to  deal  with  DIS  and  HLA  will  enable  the  ADF  to  more  easily  comply  with  both: 

•  Strategy  (COA)  2  -  Enhancing  Interoperability  in  Mixed-Architecture  Environments: 
Define  and  develop  mechanisms  to  improve  (ie  enhance)  LVC  interoperability  in  mixed 
architecture  environments,  assuming  that  the  current  architectures  will  continue  to  be 
used;  and 
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•  Strategy  (COA)  3  -  Convergence:  Develop  policy  and  incentives  to  encourage  existing 
architectures  to  converge  (over  some  defined  period  of  time)  to  either  a  single 
architecture  or  a  smaller  set  of  architectures. 

According  to  the  LVCAR  Study  the  desired  state  is  one  where  there  is  only  a  single 
architecture,  either  due  to  convergence,  or  the  creation  of  reusable  intercommunication 
resources  that  will  make  different  architecture  implementations  appear  as  a  single  resource,  or 
a  combination  of  these  two  developments. 

However,  also  according  to  the  LVCAR  study  it  is  much  less  desirable  to  seek  a  high  degree  of 
convergence  for  DIS  because  adding  the  necessary  services  to  that  protocol  would  effectively 
undermine  the  advantage  it  now  enjoys  where  it  currently  provides  the  essential 
intercommunication  services  without  adding  excessive  user  burdens  or  complexity. 

Therefore  for  the  ADF: 

•  DIS  and  HLA  account  for  most  of  the  simulation  systems  used  in  the  ADF; 

•  DIS  and  HLA  are  unlikely  to  be  able  to  be  converged  to  a  single  architecture;  and 
therefore 

•  Both  DIS  and  HLA  will  have  to  be  supported. 

5.3  Net  Warrior  Fundamental  Precepts 

The  DSTO  Net  Warrior  initiative  [Foster],  [Sioutis]  will  reflect  the  situation  found  throughout 
the  ADF  in  that  Net  Warrior  experiments  will  require  that  interoperability  be  established 
between  various  DSTO  Net  Warrior  nodes  (representing  ADF  nodes)  depending  on  the 
objectives  of  the  research  or  experimentation  undertaken. 

Sections  5.3.1  to  5.3.4  replicate  the  LVCAR  Fundamental  Precepts  (sections  4.3.1  to  4.3.4)  from 
the  Net  Warrior  point  of  view. 

5.3.1  Net  Warrior  Fundamental  Precept  #1:  Do  No  Harm. 

According  to  the  LVCAR  Study  "it  would  be  unwise  to  eliminate  support  for  any  of  the 
existing  simulation  architectures  in  the  near-term.  Rather,  as  the  differences  between  the 
architectures  are  gradually  reduced,  it  should  be  the  users  themselves  who  decide  if  and  when 
it  is  appropriate  to  merge  their  architectures  into  some  smaller  set  based  on  both  technical  and 
business  concerns.  Any  attempt  by  the  AD F/DSTO/Net  Warrior  to  mandate  a  convergence 
solution  (ie  a  single  architecture)  on  an  unwilling  user  base  is  certain  to  meet  strong 
resistance  and  likely  to  fail." 

Imagine  telling  DSTO's  Maritime  Operations  Division  that  they  had  to  (ie  were  mandated  to) 
convert  the  HLA  Virtual  Ship  Project  to  support  DIS  !!!  Not  only  would  this  be  likely  to  be 
ignored  but  in  fact  it  would  most  likely  be  extremely  difficult  to  get  the  MOD  Virtual  Ship 
simulation  system  to  interoperate  using  DIS  -  this  would  take  a  (very)  long  time  to 
implement. 

Imagine  Net  Warrior  telling  the  AOD  AOSC  DACS  (Deployable  Aircraft  Cockpit  Simulator) 
development  team  that  they  must  use  HLA  -  again  this  would  simply  be  ignored  as  there  is 
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simply  no  requirement  for  the  AOSC  DACS  systems  to  use  HLA  as  the  AOSC  has 
standardised  on  DIS  and  therefore  the  DACS  interoperates  using  DIS.  Similarly  ADGESIM 
(see  Figure  4)  has  standardised  on  DIS. 

The  recommended  Net  Warrior  (and  the  corporate  ADF)  LVC  Synthetic  Range 
Interoperability  Model  should  support  both  DIS  and  HLA  interoperability. 
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Figure  4  The  ADF  Corporate  Synthetic  Range  Interoperability  Model  Compliant  ADGESIM 


5.3.2  Net  Warrior  Fundamental  Precept  #2:  Interoperability  Is  Not  Free. 


The  necessary  investments  must  be  made  to  implement  LVC  interoperability  -  it  is  not  free.  It 
is  not  reasonable  to  expect  that  LVC  interoperability  can  be  achieved  with  little  or  no 
investment. 

Currently  each  simulation  system  itself  is  responsible  for  funding  interoperability  with  other 
simulation  systems.  There  is  no  centrally  managed  DSTO  or  AOD  task  responsible  for 
(Synthetic  Range)  Net  Warrior  interoperability  for  the  various  divisional  Net  Warrior  nodes. 
Therefore  Net  Warrior  node  interoperability  has  no  priority  or  specific  funding  and  is  actually 
resourced  as  part  of  individual  DSTO  divisional  tasks. 

There  are  no  Net  Warrior,  DSTO,  or  ADF  corporate  interoperability  standards! 
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Net  Warrior  interoperability  standards  need  to  be  tasked,  resourced  and  developed  to 
initially  reduce  risk;  and  then  move  from  reducing  risk,  towards  “Guaranteeing 
Interoperability"  which  is  far  more  difficult  to  achieve! 

5.3.3  Net  Warrior  Fundamental  Precept  #3:  Start  With  Small  Steps. 

DSTO/  AOD  should  take  immediate  action  to  improve  interoperability  among  existing  Net 
Warrior  simulation  system  architectures.  The  vast  range  of  technical  problems  currently 
associated  with  the  development  and  execution  of  mixed-architecture  LVC  environments  is 
well  recognised.  Such  problems  increase  the  technical  risk  associated  with  these  mixed- 
architecture  environments,  and  require  considerable  resources  to  address.  While  architecture 
convergence  would  lessen  (and  even  possibly  eliminate)  several  of  these  problems,  it  is  not 
practical  to  expect  any  significant  degree  of  convergence  to  occur  for  many  years. 

The  longer  you  leave  it  (ie  do  not  address  this  problem)  the  worse  it  will  get! 

The  current  work  towards  developing  a  Net  Warrior  Interoperability  Migration  Strategy 
eventually  resulting  in  Net  Warrior  Interoperability  Standards  is  an  essential  (and  initially 
a)  small  step  in  the  right  direction! 

5.3.4  Net  Warrior  Fundamental  Precept  #4:  Provide  Central  Management. 

A  set  of  Net  Warrior  Interoperability  standards  should  be  developed  or  specified  to  prevent 
further  divergence  and  to  effectively  enable  the  architecture  convergence  strategy.  Without 
any  interoperability  standards  (and  funding  to  support  development  of  individual  DSTO 
divisional  Net  Warrior  node  interoperability)  existing  architecture  communities  will  continue 
to  operate  in  line  with  their  own  self-interests,  and  the  broader  corporate  needs  of  DSTO  and 
Net  Warrior  will  be  treated  as  secondary  issues  that  are  likely  to  continue  to  be  ignored  as 
concerns  that  are  not  relevant  to  the  local  problems. 

As  per  5.3.3  -  the  current  work  towards  developing  a  Net  Warrior  Interoperability 
Migration  Strategy  eventually  resulting  in  a  Net  Warrior  Strategy  (ie  this  report)  and  Net 
Warrior  Interoperability  Standards  is  an  essential  (and  initially  a)  small  step  in  the  right 
direction!  However  it  cannot  be  allowed  to  occur  in  an  ad-hoc  fashion  -  it  must  be  (ie 
centrally)  managed,  tasked  and  resourced. 

5.4  Section  Summary 

The  Net  Warrior  initiative  is  DSTO  only  however  it  should  be  indicative  of  the  LVC 
environment  in  the  ADF. 

In  the  US  there  are  at  least  5  different  Advanced  Distributed  Simulation 
protocols/  architectures  in  use  -  DIS,  HLA,  TENA,  ALSP  and  CTIA.  In  Australia  almost  all 
LVC  systems  will  be  DIS  or  HLA. 

According  to  the  LVCAR  Study  -  DIS  should  only  be  considered  as  a  candidate  for  limited 
convergence.  DIS  should  remain  much  as  it  is  today,  a  lightweight,  core  capability  protocol. 

Therefore  for  the  ADF: 

•  DIS  and  HLA  account  for  almost  all  of  the  LVC  systems  used  in  the  ADF; 
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•  DIS  and  HLA  are  unlikely  to  be  able  to  be  converged  to  a  single  architecture;  and 
therefore 

•  Both  DIS  and  HLA  will  have  to  be  supported. 

Some  lessons  learned  from  the  US  DoD  LVCAR  Study  and  the  DSTO  Net  Warrior  initiative 
that  should  be  applicable  to  the  ADF  are: 

•  Do  No  Harm  -  Any  attempt  to  mandate  a  convergence  solution  (ie  a  single  architecture) 
on  an  unwilling  user  base  is  certain  to  meet  strong  resistance  and  is  likely  to  fail; 

•  Start  With  Small  Steps  -  The  current  work  towards  developing  a  Net  Warrior 
Interoperability  Migration  Strategy  (ie  such  as  this  report)  eventually  resulting  in  Net 
Warrior  Interoperability  Standards  is  an  essential  (and  initially  a)  small  step  in  the  right 
direction; 

•  Interoperability  is  Not  Free  -  There  are  no  Net  Warrior,  DSTO,  or  ADF  corporate 
interoperability  standards  such  as  those  being  discussed  in  this  report!  Net  Warrior 
interoperability  standards  need  to  be  tasked,  resourced  and  developed  to  initially 
reduce  risk;  but  then  move  from  reducing  risk  towards  "Guaranteeing  Interoperability" 
which  is  far  more  difficult  to  achieve;  and 

•  Provide  Central  Management  -  Unless  centrally  managed,  existing  ADF  /  DSTO  /  Net 
Warrior  LVC  communities  will  continue  to  operate  in  line  with  their  own  self-interests, 
and  the  broader  corporate  needs  of  the  ADF  /  DSTO  /  Net  Warrior  will  be  treated  as 
secondary  issues  that  are  likely  to  continue  to  be  ignored  as  concerns  that  are  not 
relevant  to  local  problems. 


6.  What  Interoperability  Models  are  Others  Using? 


6.1  Comparison  of  Synthetic  Range  Interoperability  Models 

Table  2  provides  an  analysis  of  various  coalition  LVC  systems  in  order  to  compare  their  LVC 
Synthetic  Range  Interoperability  Models  and  the  interoperability  standards  used  [Zalcman 
(2010)]. 

The  recommended  ADF  Corporate  Synthetic  Range  Interoperability  Model  (Table  3)  defines 
the  minimum  level  of  interoperability  that  all  potential  ADF  LVC  interoperable  systems 
should  be  specified  (ie  mandated)  to  have  when  acquired  by  the  Commonwealth  [Zalcman 
(2010)]. 

The  ADF  Corporate  Synthetic  Range  Interoperability  Model  shown  in  Table  3  is  only  defining 
the  required  data  at  (ie  down  to)  the  PDU  level  (ie  common  object  models).  The  objective  of 
developing  the  ADF  Corporate  Synthetic  Range  Interoperability  Model  is  that  it  would 
eventually  define  interoperability  standard  components  (DIS  PDUs  (Table  3),  DIS  PDU  fields, 
enumerations,  etc.)  precisely  and  unambiguously  so  that  each  compliant  LVC  system  should 
be  highly  specified  and  highly  interoperable  "out-of-the-box". 
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Table  2  Comparison  of  Various  Syn  thetic  Range  In  teroperability  Models. 


Model  Name 

ADS 

Radio  Comms 

Tactical  Data  Link 

USAF  (DTE5) 

DIS  IEEE  1278.1/A 
Entity  State  PDU 
Fire/Detonation  PDU 

EE  PDU 

IFF  PDU 

ASTi  DACS 

Transmitter  PDU 

Signal  PDU 

Receiver  PDU 

Link- 16 

SISO-J 

USN  (DTE5  and 
Watson  experiments) 

DIS  IEEE  1278.1/A 
Entity  State  PDU 
Fire/Detonation  PDU 

EE  PDU 

IFF  PDU 

HLA  DTE  FOM 

MaK  RTI 

ASTi  DACS 

Transmitter  PDU 

Signal  PDU 

Receiver  PDU 

Link- 1 6 

SIMPLE 

US  Army  (DTE5) 

DIS 

HLA  DTE  FOM 

MaK  RTI 

MATREX  FOM 
MATREX  RTI 

ASTi  DACS 

Transmitter  PDU 

Signal  PDU 

Receiver  PDU 

None?  (must  now  be 
VMF) 

UK  MASC 

DIS 

HLA 

DIS  Voice  Comms 
Transmitter  PDU 

Signal  PDU 

Link- 1 6 

SISO-J 

NATO  Spanish  LVC 

DIS  IEEE  1278.1/A 
HLA  IEEE  1516 
RPR-FOM  V2D17 

MaK  RTI 

Verbal 

Link- 1 6 

SISO-J  (DIS  and 

HLA) 

JADE  II  JJTTCP 

DIS  IEEE  1278.1 /A 
HLA  IEEE  1516 
RPR-FOM  V2D17 

MaK  RTI 

DLC  Compliant 

VoIP 

Link- 1 6 

JREAP 

Socket-J  /  SISO-J  ? 

NATO  NMSSP 

DIS  IEEE  1278.1/A 
HLA  IEEE  1516 
RPR-FOM  VI  and  V2 
TENA 

No  mention 

Link- 1 1  and  Link- 1 6 
SIMPLE  and  SISO-J 

Recommended  ADF 
Corporate  Synthetic 
Range  LVC 
Interoperability  Model 

DIS  IEEE  1278.1/A 
Entity  State  PDU 
Fire/Detonation  PDU 

EE  PDU 

IFF  PDU 

HLA  DoD  VI. 3  or 

IEEE  1516  equivalent 
RPR-FOM  V2D17 

DLC  Compliance 

DIS  IEEE  1278.1/A 
Transmitter  PDU 

Signal  PDU 

Receiver  PDU 

or 

HLA 

RPR-FOM  equivalent 

Link- 1 6 

JREAP 

SIMPLE 

SISO-J 
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The  ADF  Corporate  Synthetic  Range  Interoperability  Model  aims  to  guarantee  a  minimum 
(but  highly  useful)  level  of  "out-of-the-box"  corporate  LVC  interoperability  at  system  delivery 
and  acceptance  thus  reducing  risk  and  cost  to  the  ADF. 

Table  3  The  Recommended  ADF  Corporate  LVC  Synthetic  Range  Interoperability  Model. 

ADF  Corporate  Synthetic  Range  Interoperability  Model 

ADS:  DIS  IEEE  1278.1/ A 

Entity  State  PDU 
Fire  PDU 
Detonation  PDU 
Electromagnetic  Emission  PDU 
IFF  PDU 

or  equivalent 

HLA  DoD  V1.3  or  IEEE  1516 
DLC  Compliance 

FOM  is  based  on  RPR-FOM  V2D17 

Radio  Communications  :  IEEE  1278.1  Radio  Communications  Family  PDUs 

Transmitter  PDU 
Signal  PDU 

or  the  HLA  RPR-FOM  equivalents 
Tactical  Data  Link  :  Link-16 

JREAP,  SIMPLE  and  SISO-J 


Any  system  that  complies  with  the  (full)  recommended  ADF  Corporate  Synthetic  Range 
Interoperability  Model  should  be  highly  interoperable  (or  should  be  able  to  be  made  highly 
interoperable  using  cost-effective  COTS  or  GOTS  Gateways)  with  other  similar  systems  (such 
as  those  shown  in  Table  2)  as  long  as  other  synthetic  environment  parameters  (Enumerations, 
Site  IDs,  etc)  are  also  compliant.  These  other  synthetic  environment  parameters  should, 
eventually,  also  become  a  component  of  an  ADF  Corporate  Synthetic  Range  Interoperability 
Model  -  see  [Zalcman  (2003)]. 

6.2  NATO  Interoperability  Standards 

The  NATO  Modeling  and  Simulation  Standards  Profile  (NMSSP)  [NATO  NMSSP]: 
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•  Aims  to  provide  guidance  to  NATO  and  partner  organizations,  that  have  requirements  to 
effectively  use  modeling  and  simulation  (M&S).  No  standard  is  mandated  or  endorsed  by 
NATO  unless  there  is  a  related  STANAG  (NATO  Standardisation  Agreement) ;  and 

•  It  maintains  information  on  M&S  standards  and  recommended  practices  relevant  to  achieving 
M&S  interoperability  and  re-use  of  M&S  components  such  as  data,  models,  etc.  The  NMSSP 
provides  a  set  of  standards  descriptions  for  decision  making  on  options  for  the  use  of  M&S 
standards  for  NATO  activities  such  as  coalition  training  and  experimentation. 

The  NATO  NMSSP  Synthetic  Range  Interoperability  Model  (containing  interoperability 
standards  of  relevance)  is  shown  in  Table  4.The  standards  mentioned  in  Table  4  are  not  the 
only  interoperability  standards  supported/ discussed  in  the  NATO  NMSSP  however  they  are 
the  standards  relevant  to  this  current  discussion. 

Table  4  The  NATO  NMSSP  Synthetic  Range  Interoperability  Model. 

NATO  NMSSP 

ADS:  DIS  IEEE  1278.1/ A 
HLA  IEEE  1516 

DLC  Compliance 
FOM  is  based  on  RPR-FOM 
TENA 

Radio  Communications  :  No  mention 


Tactical  Data  Link  :  Link-11  and  Link-16 
SIMPLE  and  SISO-J 


Unfortunately  there  are  (at  least)  three  fundamental  flaws  in  the  NATO  NMSSP: 

•  It  does  not  support  a  complete  set  of  relevant  interoperability  standards; 

•  It  does  not  attempt  to  move  towards  guaranteeing  interoperability  -  it  only  provides 
guidance  to  reduce  risk;  and 

•  It  is  inconsistent  and  contradictory. 

6.2.1  The  NMSSP  Does  Not  Support  a  Complete  Set  of  Interoperability  Standards 

The  NATO  NMSSP  lacks  standards  related  to  Live  simulations  such  Live  radio  and  the  JREAP 
Link-16  transport  protocol. 

The  NATO  NMSSP  does  not  include  the  JREAP  Link-16  transport  protocol  [MIL-STD-3011].  It 
should  include  the  JREAP  standard  otherwise  systems  that  only  use  interoperability 
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standards  recommended  in  the  NATO  NMSSP  may  be  restricted  to  only  supporting  JTIDS 
and  MIDS  Link-16  communications  systems  (ie  no  SATCOM  systems).  The  fact  that  JREAP  is 
not  in  the  NATO  NMSSP  is  a  deficiency  of  the  NMSSP  -  it  is  not  a  deficiency  in  the 
recommended  ADF  Corporate  Synthetic  Range  Interoperability  Model. 

Not  supporting  JREAP  in  the  NATO  NMSSP  can  be  overcome  by  using  a  COTS  product  such 
as  a  Northrop  Grumman  Gateway  Manager  to  translate  (ie  Gateway)  between  SIMPLE,  SISO-J 
and  JREAP. 

The  NATO  NMSSP  does  not  appear  to  support  LVC  Radio  Communications  interoperability 
standards  as  there  is  no  mention  of  any  real  radio  system  standards.  The  Virtual  and 
Constructive  LVC  component  Radio  Communications  interoperability  standards  are  covered 
by  the  IEEE  1278.1  (ie  DIS)  Radio  Communications  PDU  Family  and  their  HLA  (through  the 
RPR-FOM)  (and  TENA)  equivalents. 

6.2.2  The  NMSSP  Does  Not  Attempt  to  Guarantee  Interoperability  -  It  Can  Only 
Provide  Guidance  and  Reduce  Risk 

The  NMSSP  does  not  precisely  and  unambiguously  define  what  is  required  for  LVC 
interoperability  (DIS  PDUs,  DIS  PDU  fields,  enumerations,  etc.  -  sections  9  and  10)  so  that 
each  compliant  LVC  system  would  be  highly  interoperable  "out-of-the-box"-  it  simply  defines 
what  interoperability  standards  should  be  considered.  As  such  the  objective  of  the  NMSSP 
appears  to  be  more  to  reduce  risk  rather  than  attempt  to  move  towards  guaranteeing 
interoperability. 

6.2.3  The  NMSSP  Is  Inconsistent  and  Contradictory 

The  NATO  NMSSP  actually  contradicts  itself  in  that  it  supports  the  use  of  DIS,  HLA  and 
TENA  however  HLA  is  a  promulgated  NATO  Standard  (STANAG  4603)  which  means  that 
NATO  requires  the  use  of  HLA! 

The  NATO  NMSSP  also  mentions  that  the  results  of  the  recently  released  US  DoD  LVC 
Architecture  Roadmap  Study  [LVCAR-1],  [LVCAR-2]  were  not  available  for  the  NMSSP. 

The  objective  of  the  NATO  Modelling  and  Simulation  Standards  Profile  (NMSSP)  is  to 
provide  guidance  regarding  modelling  and  simulation  standards  and  processes  to  NATO  and 
partner  nations  recognising  that  "one  size  does  not  fit  all".  However  the  NATO  NMSSP 
should  at  least  contain  all  the  LVC  interoperability  standards  that  should  be  considered  when 
developing  a  Synthetic  Range  Interoperability  Model. 

Even  with  the  interoperability  standards  recommended,  the  NATO  NMSSP  does  not 
recommend  or  define  a  minimum  level  (or  any  level)  of  interoperability  that  all  LVC  systems 
should  have  -  it  does  not  recommend  a  set  of  standards  that  should  be  used  -  it  provides 
guidance  and  a  list  of  standards  that  should  be  considered.  It  also  does  not  define  individual 
interoperability  standard  components  precisely  and  unambiguously.  It  simply  specifies  a 
library  of  standards  that  should  be  selected  from  when  developing  a  LVC  system. 

The  NATO  NMSSP  does  not  recommend  PDUs  or  PDU  fields  -  which  the  ADF  Corporate 
Synthetic  Range  Interoperability  Model  eventually  will  do.  Unless  all  the  relevant  "bits  and 
bytes"  are  unambiguously  and  precisely  defined,  a  LVC  system  could  be  delivered  with  DIS 
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or  (especially)  HLA  implemented  and  not  be  interoperable  with  other  similarly  specified  LVC 
systems  [Tudor].  The  NATO  NMSSP  only  provides  limited  guidance  -  it  simply  reduces  risk 
but  it  does  not  move  towards  guaranteeing  interoperability  at  any  level  as  it  does  not 
precisely  and  unambiguously  define  what  needs  to  be  defined!  Exactly  how  this  can  be  done 
is  discussed  in  section  9  of  this  report. 

Of  the  coalition  systems  analysed  the  UK  LVC  systems  [Khetia],  [Zalcman  (2010)]  appear  to  be 
highly  interoperable  with  the  USAF  DMO  systems  as  they  appear  to  use  very  similar  (if  not 
identical)  interoperability  standards  -  a  high  level  of  compliance  with  USAF  DMO 
interoperability  standards  is  also  the  intention  of  the  recommended  ADF  Corporate  Synthetic 
Range  Interoperability  Model. 


6.3  Section  Summary 

From  the  literature.  Table  2  [Zalcman  (2010)]  shows  the  various  Synthetic  Range 
Interoperability  Models  used  in  recent  experiments  and  exercises. 

Any  LVC  system  that  is  compliant  with  the  recommended  ADF  Corporate  Synthetic  Range 
Interoperability  Model  (shown  in  Table  3)  should  be  highly  interoperable  with  the  systems 
shown  in  Table  2  as  long  as  other  relevant  synthetic  environment  parameters  such  as 
Enumerations,  Site  IDs,  etc.  (which  eventually  will  also  become  part  of  the  ADF  Corporate 
Synthetic  Range  Interoperability  Model),  and  appropriate  gateways,  are  also  compliant. 

The  objective  of  the  NATO  Modelling  and  Simulation  Standards  Profile  (NMSSP)  is  to 
provide  guidance  regarding  modeling  and  simulation  (M&S)  standards  and  processes  to 
NATO  and  partner  nations  [NATO  NMSSP] . 

Unfortunately  there  are  (at  least)  three  fundamental  flaws  in  the  NATO  NMSSP: 

•  It  does  not  support  a  complete  set  of  relevant  LVC  interoperability  standards  such  as 
real,  operational  radio  (ie  Live  radio  communications)  and  the  JREAP  Link-16  transport 
protocol; 

•  It  does  not  attempt  to  move  towards  guaranteeing  interoperability  -  it  simply  provides 
a  list  of  interoperability  standards  that  should  be  considered,  that  is  it  only  provides 
guidance  to  reduce  risk;  and 

•  It  is  inconsistent  and  contradictory  in  that  the  NATO  NMSSP  supports  the  use  of  DIS, 
HLA  and  TENA  however  HLA  is  a  promulgated  NATO  Standard  (STANAG  4603)  and 
should  therefore  be  mandated. 
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7.  A  Cost-Effective  Synthetic  Range  Interoperability 
Model  for  Virtual  and  Constructive  Systems 

The  recommended  ADF  Synthetic  Range  Interoperability  Model,  as  discussed  so  far,  is  shown 
in  Table  3.  This  model  addresses  interoperability  for  LVC  systems  down  to  the  level  of 
specifying  what  DIS  PDUs  need  to  be  supported.  HLA  systems  track  these  PDUs  through  the 
use  of  the  HLA  RPR-FOM  [RPR-FOM-2], 

Table  5  The  Simplified  Virtual  and  Constructive  ADF  Corporate  Synthetic  Range  Interoperability 
Model. 

ADF  Corporate  Virtual  and  Constructive  Synthetic  Range 

Interoperability  Model 

ADS:  DIS  IEEE  1278.1/ A 

Entity  State  PDU 
Fire  PDU 
Detonation  PDU 
Electromagnetic  Emission  PDU 
IFF  PDU 

or  equivalent 

HLA  DoD  V1.3  or  IEEE  1516 
DLC  Compliance 

FOM  is  based  on  RPR-FOM  V2D17 

Radio  Communications  :  IEEE  1278.1  Radio  Communications  Family  PDUs 

Transmitter  PDU 
Signal  PDU 

or  the  HLA  RPR-FOM  equivalents 
Tactical  Data  Link  :  Link-16  encapsulated  in  SISO-J 


For  virtual  or  constructive  simulation  systems  (ie  no  Live  systems)  the  Synthetic  Range 
Interoperability  Model  can  be  simplified  further  by  requiring  that  only  the  SISO-J  transport 
protocol  [SISO-STD-002-2006]  be  supported  for  Link-16  Tactical  Data  Link  interoperability. 
The  model  then  reduces  to  that  shown  in  Table  5  and  Figure  5  where  compliance  with  this 
model  can  be  fully  achieved  using  only  DIS  or  HLA.  In  this  situation  specialised  Tactical  Data 
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Link  hardware  and  software  is  not  required  because  SISO-J  is  supported  in  DIS  or  HLA 
thereby  (potentially)  reducing  considerably  the  software  and  hardware  (ie  cost  and  risk) 
required  for  such  systems. 


IEEE  1278.1ADIS(orHLA)  Network 

(including  SISO-J  TDL) 

Figure  5  The  (Generic)  Virtual  and  Constructive ,  Synthetic  Range  Interoperability  Model. 

This  simplified,  and  more  cost-effective.  Virtual  (and  Constructive)  Synthetic  Range 
Interoperability  Model  has  been  used  by  DSTO  to  develop  interoperability  for  the  high- 
fidelity  ADGESIM  (Air  Defence  Ground  Environment  SIM)  simulation  system  (Figure  4) 
[Zalcman  (2009)  - 1],  [Zalcman  (2009)  -  2]  used  by  the  RAAF  to  train  Air  Combat  Officers. 

This  also  appears  to  be  the  Synthetic  Range  Interoperability  Model  supported  by  the  USAF  - 
see  Table  2. 

Some  legacy  Virtual  and  Constructive  systems  may  support  Link-16  interoperability  but  not 
using  the  SISO-J  TDL  transport  protocol.  Such  systems  will  require  access  to  an  appropriate 
TDL  Gateway  device,  such  as  a  Northrop-Grumman  Gateway  Manager  system,  to  comply 
with  the  Virtual  (and  Constructive)  Synthetic  Range  Interoperability  Model  shown  in  Table  5. 


7.1  Section  Summary 

For  virtual  or  constructive  simulation  systems  (ie  no  Live  systems)  the  Synthetic  Range 
Interoperability  Model  can  be  simplified  further  by  requiring  that  only  the  SISO-J  transport 
protocol  [SISO-STD-002-2006]  be  supported  for  Link-16  Tactical  Data  Link  interoperability. 
The  model  then  reduces  to  that  shown  in  Table  5  and  Figure  5,  where  compliance  with  this 
model  can  be  fully  achieved  using  only  DIS  or  HLA.  In  this  situation  specialised  Tactical  Data 
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Link  hardware  and  software  is  not  required  because  SISO-J  is  supported  both  in  DIS  and  HLA 
thereby  reducing  considerably  the  software  and  hardware  (ie  cost  and  risk)  required  for  such 
systems. 


8.  How  Do  We  Proceed  from  Here? 


The  US  DoD  LVCAR  Study  considered  five  advanced  distributed  simulation  architectures 
that  are  in  use  in  the  USA.  Figure  3  shows  the  relative  use  of  these  architectures  in  the  US  as 
surveyed  by  the  LVCAR  Study. 

In  Australia,  although  there  may  be  some  use  of  the  minor  architectures  (mainly  in  COTS 
systems),  the  vast  majority  of  distributed  simulation  systems  would  be  either  DIS  or  HLA 
systems  where: 

•  DIS:  This  protocol  has  a  comparatively  low  barrier  to  entry;  it  is  relatively  simple  to 
learn  and  easy  to  use.  Also,  it  imposes  a  very  low  overhead.  Whenever  simulation 
events  do  not  require  using  more  advanced  architectural  services  (such  as  time 
management,  region-based  information  filtering,  and  so  on),  DIS  offers  a  very 
economical  solution  to  the  system  intercommunication  problem  [LVCAR  - 1],  [LVCAR 
-  2];  and 

•  HLA:  This  architecture  can  serve  a  disparate  collection  of  simulation  systems,  including 
those  that  require  advanced  architectural  services  and  those  that  have  modest 
requirements.  In  addition  to  its  large  US  user  base,  its  standing  as  an  international 
standard  has  resulted  in  a  large  level  of  use  in  the  coalition  partner  countries, 
facilitating  combined  simulation  events  that  include  multiple  nations  [LVCAR  -  1], 
[LVCAR -2]. 

However  also  according  to  the  LVCAR  Study 

"DIS  should  only  be  considered  as  a  candidate  for  limited  convergence.  This  protocol 
provides  unique  services  and  capabilities  that  would  be  lost  were  the  protocol  to  be  fully 
converged  with  other  architectures  that  serve  different  communities  and  necessarily 
provide  higher  levels  of  service  capability.  Wltile  some  of  the  activities  that  could  lead  to 
more  service-level  compatibility  (e.g.,  common,  components  of  object  models,  standard 
wire-level  protocols,  etc.)  between  DIS  and  the  other  architectures  will  prove 
advantageous,  DIS  should  remain  much  as  it  is  today,  a  lightweight,  core  capability 
protocol"; 

Of  the  five  initial,  potential  LVCAR  strategies  two  were  finally  recommended: 

•  Actively  Manage  the  Existing  Architectures  -  Create  standard  inter-architecture 
integration  solutions.  Keep  the  current  multiple  architectures  but  invest  in  improving 
the  construction  /  performance  /  integration  of  various  gateways,  translators,  object 
models,  and  create  processes  and  procedures  to  make  inter-architecture  integration 
"faster,  easier,  cheaper";  and 
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•  Convergence  -  Create  policy  and  procedures,  and  provide  small  amounts  of  seed 
money,  to  encourage  the  architectures  to  converge  with  one  another  in  the  long-term 
time  frame  (e.g.,  10  years).  When  they  become  so  similar  in  features  and  capabilities, 
engineer  the  merging  of  them  into  a  single  architecture. 

Therefore  because  the  vast  majority  of  LVC  systems  in  Australia  will  be  DIS  or  HLA;  and  D IS 
should  remain  much  as  it  is  today,  the  LVCAR  Convergence  strategy  cannot  really  apply  in 
Australia.  In  Australia  DIS  and  HLA  will  remain  as  two  separate  architectures  /  protocols  - 
both  DIS  and  HLA  need  to  be  supported. 

However  the  LVCAR  Actively  Manage  the  Existing  Architectures  strategy  "to  invest  in 
improving  the  construction  /  performance  /  integration  of  various  gateways,  translators,  object  models, 
and  create  processes  and  procedures  to  make  inter-architecture  integration  "faster,  easier,  cheaper"  can 
apply  in  Australia. 

This  current  report  focuses  on  the  common  object  model  component  of  the  Actively  Manage 
the  Existing  Architectures  LVCAR  Study  strategy.  Unless  LVC  systems  have  such  common 
object  models  (ie  common  data)  gateways,  translators,  etc.  will  not  be  able  to  work  as  there 
will  be  no  common  data  for  translators  or  gateways  to  work  on! 


8.1  The  DIS  (Common)  Object  Model 

In  DIS  it  is  the  DIS  Protocol  Data  Unit  (PDU)  that  is  the  main  component  of  the  DIS  "object 
model". 

The  structure  of  DIS  PDUs  (the  PDU  data  fields)  and  how  (ie  the  format)  the  data  is  packed 
into  these  PDU  data  fields  is  defined  in  the  IEEE  DIS  standards  -  the  latest  relevant  standards 
are  the  IEEE  1278.1  standard  [DIS  (1995)]  and  the  incremental  1278.1  upgrade  -  the  IEEE 
1278. 1A  standard  [DIS  (1998)]. 

The  DIS  PDU  is  transmitted  around  a  network  encapsulated  in  a  higher  level  standard 
computer  internet  network  packet/ protocol  known  as  UDP  (User  Datagram  Protocol). 
Therefore  the  format  of  any  particular  DIS  PDU  on  the  network  is  fixed  -  it  is  the  same  for  all 
DIS  applications  and  the  structure,  and  the  format,  of  the  DIS  PDU  is  what  is  actually  defined 
in  the  IEEE  DIS  standards  -  all  DIS  programs  "speak  the  same  language"!  Because  the  DIS 
PDU  data  on  the  network  (ie  the  "wire")  is  always  structured  in  the  same  way  (ie  as  defined 
in  the  IEEE  DIS  standards)  DIS  is  sometimes  referred  to  as  a  "wire  standard". 

Because  DIS  is  a  wire  standard  DIS  applications  from  different  manufacturers  can  interoperate 
as  long  as  they  support  IEEE  standard  DIS  PDUs,  and  populate  the  same  fields  in  the  same 
PDUs  with  the  same  common  set  of  enumeration  data. 

A  new  version  of  the  DIS  standard  (to  be  known  as  IEEE-1278-2011)  is  due  to  complete  its 
IEEE  balloting  process  (actually  carried  by  SISO  -  the  Simulation  Interoperability  Standards 
Organization  [SISO])  in  2011.  According  to  Ryan  et  al.  [Ryan]  the  proposed  new  IEEE-1278- 
2011  standard  is  an  extensive  revision  that  clarifies  ambiguities  present  in  the  current 
standard,  adds  new  capabilities  that  reflect  changes  in  military  equipment  and  doctrine,  and 
provides  for  advances  in  technologies  such  as  the  Internet,  mobile  telephony,  computing  and 
the  widespread  use  of  the  Global  Positioning  System  for  positional  and  time  data. 
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8.2  Common  Architecture  /  Protocol  Independent  Enumerations 

The  data  that  populates  the  DIS  PDUs  (ie  the  data  present  in  the  DIS  PDU  data  fields)  is 
defined  in  another  (SISO)  standard  "Enumeration  and  Bit  Encoded  Values  for  Use  with 
Protocols  for  Distributed  Interactive  Simulation  (ie  DIS)  Applications"  [SISO-REF-OIO].  This 
standard  is  also  in  the  process  of  being  updated  and  the  new  2010  version  of  the 
Enumerations  Document  standard  will  be  referred  to  as  SISO-REF-010-2010.  When  released 
this  standard  should  be  available  from  the  SISO  web  site  [SISO-REF-OIO]. 

Although  the  title  of  the  Enumerations  Data  standard  refers  specifically  to  its  use  for  DIS 
systems  the  enumerations  are  widely  used  in  other  architecture  /  protocol  LVC  systems  (eg. 
HLA,  TENA).  If  this  approach  was  not  adopted  each  architecture  or  protocol  would  have  its 
own  enumeration  standard  and  (even  more  complex)  protocol  translators  and  gateways 
would  be  required  to  provide  interoperability  between  the  different  distributed  simulation 
architectures  and  protocols. 


8.3  The  HLA  (Common)  Object  Model 

A  LILA  simulation  system  (known  as  a  Federation)  is  comprised  of  several  HLA 
simulators/ simulations  (Federates)  interoperating  with  each  other,  and  with  other 
Federations.  The  HLA  Federates  interoperate  with  each  other  through  the  HLA  Run-Time 
Infrastructure  (RTI).  The  RTI  provides  a  standard  Application  Programmers  Interface  (API)  -  a 
standard  programming  interface  which  enables  HLA  Federates  to  interoperate  through  API 
calls  to  the  HLA  RTI.  The  HLA  RTI  APIs  are  defined  in  an  IEEE  standard  such  as  IEEE  1516.1 
[HLA  (2000)  -  2], 

This  why  HLA  is  sometimes  referred  to  as  an  "API  standard"  because  the  HLA  software  is 
always  structured  in  the  same  way  (makes  the  same  structured  RTI  API  calls)  as  defined  in 
the  relevant  HLA  standard.  You  can  therefore  re-use  HLA  software  with  different 
manufacturers  RTIs. 

However  HLA  RTIs  are  produced  by  industry  (and  military)  and  how  HLA  packets  appear  on 
the  network  is  not  defined  -  this  information  is  proprietary.  HLA  is  an  "API  standard"  not  a 
"wire  standard"  and  HLA  applications  that  do  not  use  exactly  the  same  version  of  the  same 
manufacturer's  HLA  RTI  are  not  guaranteed  to  interoperate  -  they  do  not  "speak  the  same 
language" !  Therefore  you  can  re-use  HLA  software  but  only  if  all  Federates  and  Federations 
use  the  same  manufacturer's  RTI. 

HLA  Federations  that  use  different  RTIs  may  require  specifically  designed  Bridges  to 
interoperate.  Federation  HLA  interoperability  can  be  extremely  complex  (and  difficult) 
[Tudor]! 

HLA  is  more  flexible  than  DIS.  However  this  additional  flexibility  comes  at  the  cost  of 
additional  complexity,  difficulty,  and  possibly  cost,  when  making  HLA  Federations 
interoperable.  How  the  data  is  structured  (defined  in  the  HLA  object  model)  is  determined  by 
the  HLA  application  developer  and  is  known  as  the  HLA  Federation  Object  Model  (FOM).  A 
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Federation  Object  Model  is  a  specification  defining  the  information  exchanged  between 
federates  at  runtime  (ie )  and  includes  object  classes,  object  class  attributes,  interaction  classes, 
interaction  parameters  and  other  relevant  information  [RPR-FOM-1]. 

Each  LILA  Federate  has  its  own  Simulation  Object  Model  (SOM)  that  defines  the  object  model 
for  that  particular  Federate.  A  SOM  specifies  the  types  of  information  that  an  individual 
federate  can  provide  to,  and  receive  from  (known  as  publish  and  subscribe  in  FILA 
terminology),  other  federates  in  HLA  federations. 

During  the  development  of  FILA  the  concept  of  a  Reference  FOM  was  developed.  The  goal  of 
a  Reference  FOM  is  to  enhance  a-priori  interoperability  by  specifying  content  standards  for 
common  capabilities.  Building  upon  the  Reference  FOM  (where  each  federation's  changes 
only  extend  this  core  Reference  FOM's  functionality)  to  meet  the  needs  of  a  given  FILA 
execution  creates  the  FOM  for  a  particular  federation  [RPR-FOM-1]. 

The  Real-time  Platform  Reference  Federation  Object  Model  (RPR-FOM,  pronounced  "reaper 
fom")  was  specifically  designed  to  support  interoperability  between  DIS  and  FILA  systems 
and  enhance  a-priori  interoperability  among  FILA  RPR-FOM  users  (see  section  3.2.3). 

Like  DIS,  the  RPR  FOM  is  designed  to  support  real  time  simulations  of  discrete  physical 
entities  such  as  planes,  ships,  soldiers,  munitions,  etc.  These  simulations  are  considered  "real¬ 
time"  because  each  second  of  elapsed  execution  time  is  equivalent  to  one  second  of  time  in  the 
virtual  world.  Real-time,  platform  simulations  are  often  used  to  support  man-in-the-loop  or 
hardware-in-the-loop  systems  [RPR-FOM-1]. 

Version  1.0  of  the  RPR-FOM  provides  a  HLA  translation  path  for  the  DIS  capabilities  defined 
in  IEEE  1278.1  [DIS  (1995)]  standard.  Version  2  of  the  RPR-FOM  was  meant  to  add  the 
functionality  of  the  IEEE  1278.1 A  standard  [DIS  (1998)].  However  RPR-FOM  Version  2  was 
never  "standardized". 

This  is  why  all  the  Synthetic  Range  Interoperability  Model  tables  (eg  the  recommended  ADF 
Corporate  Synthetic  Range  Interoperability  Model  described  in  Table  3)  refer  to  the  HLA  RPR- 
FOM  as  this  HLA  FOM  provides  support  for  the  HLA  equivalent  of  DIS. 

This  report  will  focus  specifically  on  DIS  interoperability.  However  interoperability  between 
DIS  and  RPR-FOM  based  HLA  LVC  systems  can  be  provided  by  DIS/ HLA  Gateways  whose 
HLA  FOM  is  based  on  the  HLA  RPR-FOM.  Such  DIS/HLA  Gateways  can  be  purchased  as 
COTS  products  from  RTI  manufacturers  eg  the  MaK  Technologies  [MaK]  DIS/HLA  Gateway 
product  enables  interoperability  between  IEEE  1278. 1A  and  HLA  LVC  systems  (using  the 
Mak  Technologies  HLA  RTI  and  the  RPR-FOM). 

HLA  interoperability  is  complex  and  exactly  how  HLA  (and  HLA  and  DIS)  systems 
interoperate  depends  on  whether  source  code  is  available,  which  manufacturer's  RTI  has  been 
used,  which  FOM  has  been  used,  and  which  version  of  HLA  (US  DoD  V1.3,  IEEE  1516,  HLA 
Evolved)  has  been  used  [Tudor], 

8.4  Section  Summary 

The  LVCAR  Study  investigated  five  potential  strategies  (section  4.5): 

•  Status  Quo  or  "Do  Nothing"; 


UNCLASSIFIED 


51 


UNCLASSIFIED 


DSTO-GD-0645 

•  Actively  Manage  the  Existing  Architectures; 

•  Convergence; 

•  Select  One  of  the  Existing  Architectures;  and 

•  Develop  A  New  Architecture. 

Of  these  five  initial,  potential  LVCAR  strategies  two  were  finally  recommended: 

•  Actively  Manage  the  Existing  Architectures  -  Create  standard  inter-architecture 
integration  solutions.  Keep  the  current  multiple  architectures  but  invest  in  improving 
the  construction  /  performance  /  integration  of  various  gateways,  translators,  object 
models,  and  create  processes  and  procedures  to  make  inter-architecture  integration 
"faster,  easier,  cheaper";  and 

•  Convergence  -  Create  policy  and  procedures,  and  provide  small  amounts  of  seed 
money,  to  encourage  the  architectures  to  converge  with  one  another  in  the  long-term 
time  frame  (e.g.,  10  years).  When  they  become  so  similar  in  features  and  capabilities, 
engineer  the  merging  of  them  into  a  single  architecture. 

The  US  LVCAR  Study  found  that  five  advanced  distributed  simulation  architectures  are 
commonly  in  use  in  the  US  -  see  Figure  3. 

In  Australia  the  vast  majority  of  distributed  simulation  systems  would  be  either  DIS  or  HLA 
systems  where: 

•  DIS  -  has  a  low  barrier  to  entry;  is  simple  to  learn  and  easy  to  use;  and  imposes  a  very 
low  overhead.  Whenever  simulation  events  do  not  require  the  use  of  more  advanced 
architectural  services  DIS  offers  a  very  economical  solution  to  interoperability  [LVCAR 
-  1],  [LVCAR  -  2];  and 

•  HLA  -  can  serve  a  disparate  collection  of  simulation  systems  including  those  that 
require  advanced  architectural  services  and  is  in  considerable  use  in  the  US  and  in  the 
coalition  partner  countries  [LVCAR  -  1],  [LVCAR  -  2], 

Because  the  LVCAR  Study  recommends  that  DIS  should  remain  much  as  it  is  today,  the 
Convergence  strategy  cannot  really  apply  in  Australia  and  DIS  and  HLA  will  need  to  remain 
and  be  supported  as  two  separate  architectures  /  protocols. 

However  the  LVCAR  Actively  Manage  the  Existing  Architectures  strategy  “to  invest  in 
improving  the  construction  /  performance  /  in  tegration  of  various  gateivays,  translators,  object  models, 
and  create  processes  and  procedures  to  make  in  ter-architecture  integration  “ faster ,  easier,  cheaper"  can 
apply  in  Australia. 

In  DIS  the  DIS  Protocol  Data  Unit  (PDU)  is  a  main  component  of  the  DIS  "object  model".  The 
structure  of  DIS  PDUs  (the  PDU  data  fields),  and  how  the  data  is  packed  into  these  PDU  data 
fields,  are  defined  in  the  IEEE  1278.1  standard  [DIS  (1995)]  and  the  incremental  (ie  upgrade) 
IEEE  1278.1 A  standard  [DIS  (1998)].  A  new  version  of  the  DIS  standard  (IEEE-1278-2011)  is 
due  to  complete  its  IEEE  balloting  process  in  2011. 

HLA  is  more  flexible  than  DIS.  However  this  flexibility  comes  at  the  cost  of  complexity  (and 
most  likely  financial  cost)  when  making  HLA  Federations  interoperable.  The  HLA  object 
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model  is  determined  by  the  HLA  Federation  developer  and  is  known  as  the  HLA  Federation 
Object  Model  (FOM).  A  Federation  Object  Model  is  a  specification  defining  the  information 
exchanged  between  federates  at  runtime  and  includes  object  classes,  object  class  attributes, 
interaction  classes,  interaction  parameters  and  other  relevant  information  [RPR-FOM-1].  Each 
LILA  Federate  has  its  own  Simulation  Object  Model  (SOM)  that  defines  the  object  model  for 
the  Federate.  A  SOM  specifies  the  types  of  information  that  an  individual  federate  can  provide 
to,  and  receive  from,  other  federates  in  LILA  federations. 

The  Real-time  Platform  Reference  Federation  Object  Model  (the  RPR-FOM)  was  designed  to 
support  and  enhance  a-priori  interoperability  between  DIS  and  FILA  systems  built  on  the 
FFLA  RPR-FOM  (see  section  3.2.3)  as  a  starting  point.  This  report  will  focus  specifically  on  DIS; 
however  interoperability  between  DIS  and  RPR-FOM  based  FILA  LVC  systems  can  be 
provided  by  COTS  or  GOTS  DIS/FLLA  Gateways. 

A  list  of  common  SISO  standard  [SISO-REF-OIO],  protocol  independent  enumerations  can  be 
specified  to  be  delivered  with  all  ADF  LVC  systems  -  see  section  10.3  also. 


9.  What  Exactly  Does  "Compliance  With  a  Synthetic 
Range  Interoperability  Model"  Mean? 


9.1  An  Interoperability  Standards  Based  Approach 

Interoperability  among  LVC  systems  within  a  common  scenario  requires  compliance  with  an 
agreed  set  of  interoperability  standards  including  network  infrastructure,  data, 
interoperability  protocols,  platform  /  environmental  representation,  etc  [Aldinger].  This 
requires  the  development  of  a  Synthetic  Range  Interoperability  Model  (a  set  of  (LVC) 
interoperability  standards)  that  is  a  crucial  part  of  any  synthetic  range  architecture.  All 
synthetic  range  systems  that  are  compliant  with  such  a  Synthetic  Range  Interoperability 
Model  should  be  highly  interoperable  regardless  of  whether  the  systems  are  Live,  Virtual  or 
Constructive. 

Participants  in  USAF  Distributed  Mission  Operations  (DMO)  training  events  must  use 
systems  and  processes  that  comply  with  USAF  DMO  interoperability  standards.  They  must  be 
certified  (ie  accredited)  for  participation  (ie  comply  with  DMO  standards)  before  being  able  to 
begin  system  integration  activities  on  the  DMO  Network.  All  DMO  systems  must  adhere 
strictly  to  this  rigid  set  of  interoperability  standards  and  processes.  This  standards  based 
approach  architecture  has  been  developed  to  provide  a  high-reliability,  routine,  robust, 
scalable  and  reliable,  global  Virtual-Constructive,  daily  training  capability  for  the  war-fighter 
[Aldinger], 

The  US  Army's  LVC  Integrating  Architecture  (LVC-IA)  is  also  moving  towards  this  same 
approach  of  developing  interoperability  and  integration  standards,  guidelines  and  processes 
with  the  objective  of  introducing  this  standards-based  approach  back  into  the  US  Army's  base 
programs  [Lyders]. 
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9.2  A  Synthetic  Range  Interoperability  Model  Must  Be  A  Mandated 
Model! 

All  specifications  defined  in  a  Synthetic  Range  Interoperability  Model  must  be  mandated  -  all 
specifications  (DIS  PDUs,  PDU  fields,  enumerations  data,  etc.)  in  a  Synthetic  Range 
Interoperability  Model  must  be  implemented  in  a  LVC  system  that  intends  to  comply  with 
that  particular  Synthetic  Range  Interoperability  Model. 

Once  a  Synthetic  Range  Interoperability  Model  has  been  precisely  and  unambiguously 
defined,  common  RFT  specifications  and  common  associated  test  and  acceptance  procedures 
for  that  particular  Synthetic  Range  Interoperability  Model  can  be  developed  [Ross]. 


9.3  Only  Accredited  Systems  Can  Participate  In  LVC  Activities 

The  same  RFT  specifications,  and  associated  test  and  acceptance  procedures  will  be  used  to 
specify  and  test  any  LVC  system  that  is  to  comply  with  that  particular  Synthetic  Range 
Interoperability  Model. 

Once  a  LVC  system  has  been  tested  against  the  specifications  of  that  particular  Synthetic 
Range  Interoperability  Model,  thereby  determining  that  the  system  complies  with  all  the 
standard  requirements  of  that  particular  Synthetic  Range  Interoperability  Model,  the  system 
receives  accreditation  that  it  complies  with  that  particular  Synthetic  Range  Interoperability 
Model. 

Accreditation  is  a  process  in  which  certification  of  competency,  authority,  or  credibility 
is  presented. 

Organizations  that  issue  credentials  or  certify  third  parties  against  official  standards  are 
themselves  formally  accredited  by  accreditation  bodies  (such  as  IEEE);  hence  they  are 
sometimes  known  as  " accredited  certification  bodies".  The  accreditation  process  ensures 
that  their  certification  practices  are  acceptable,  typically  meaning  that  they  are  competent 
to  test  and  certify  third  parties,  behave  ethically  and  employ  suitable  quality  assurance. 
[Accreditation] 

A  LVC  system  cannot  participate  (ie  begin  system  integration  activities)  in  a  LVC  activity 
unless  that  LVC  system  has  been  certified  (ie  has  received  accreditation)  for  participation  (ie  is 
compliant  with  the  Synthetic  Range  Interoperability  Model  specified  for  use)  in  that  particular 
activity  or  exercise. 

9.4  A  Synthetic  Range  Interoperability  Model  Is  A  Minimalistic  Model! 

"Minimalism  describes  movements  in  various  forms  of  art  and  design  where  the  work  is 
stripped  down  to  its  most  fundamental  features."  [Minimalism] 

Systems  compliant  with  the  Synthetic  Range  Interoperability  Model  specified  in  Table  3  can 
exceed  or  enhance  the  interoperability  (standards)  specified.  For  example  a  high-fidelity. 
Frigate  LVC  system  would  most  likely  support  a  Sonar  (Underwater  Acoustic)  capability  in 
addition  to  the  Synthetic  Range  Interoperability  Model  specified  in  Table  3.  The  DIS 
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Underwater  Acoustic  PDU  is  not  part  of  the  Synthetic  Range  Interoperability  Model  specified 
in  Table  3  because  Table  3  defines  an  (minimalistic)  ADF  Corporate  Synthetic  Range 
Interoperability  Model.  An  Army  M1A1  Abrahams  tank  or  a  F/  A-18  fighter  has  no 
requirement  for  any  Underwater  Acoustic  capability! 

Flowever,  a  DIS  Underwater  Acoustic  PDU  would  most  likely  be  part  of  a  Royal  Australian 
Navy  Synthetic  Range  Interoperability  Model  which  would  be  built  upon  the  ADF  Corporate 
Synthetic  Range  Interoperability  Model. 

Compliance  with  a  Synthetic  Range  Interoperability  Model  does  not  restrict  what  additional 
interoperability  a  compliant  system  can  support.  Flowever,  compliance  does  require  support 
for  a  minimum  set  of  interoperability  components  /  capabilities  (eg  PDUs  for  DIS)  specified  in 
the  particular  Synthetic  Range  Interoperability  Model. 

9.5  Compliance  With  A  Synthetic  Range  Interoperability  Model  Does  Not 
Mean  That  All  Specified  PDUs  Are  Always  Supported! 

Interoperability  (from  a  DIS  point-of-view)  with  the  ADF  Corporate  Synthetic  Range 
Interoperability  Model  shown  in  Table  5  can  be  alternatively  specified  as  shown  in  Table  6. 


Table  6  An  Alternative  (DIS)  View  of  the  Simplified  ADF  Virtual  and  Constructive  Corporate 
Synthetic  Range  Interoperability  Model  as  described  in  Table  5. 


ADF  Corporate  Virtual  and  Constructive  Synthetic  Range  Interoperability 

Model 

DIS  PDUs 

Data  Functionality 

Entity  State  PDU 

Entity  Information 

Fire  PDU 

Weapon  Information 

Detonation  PDU 

Weapon  Information 

Electromagnetic  Emission  PDU 

Sensor  Information 

IFF  PDU 

IFF  Information 

Transmitter  PDU 

Radio  Communications  Information 

Signal  PDU 

Radio  Communications  Information 

Transmitter  PDU  (SISO-J) 

Tactical  Data  Link  Information 

Signal  PDU  (SISO-J) 

Tactical  Data  Link  Information 

Flowever  compliance  with  a  specific  Synthetic  Range  Interoperability  Model  does  not  mean 
that  all  the  specified  PDUs  are  always  supported.  For  example,  if  a  high-fidelity,  simulation 
system  for  a  single-engine,  Cessna  172  "Skyhawk"  aircraft  (shown  in  Figure  6  and  used  by 
some  military  forces)  were  to  be  developed,  compliance  with  the  Synthetic  Range 
Interoperability  Model,  as  shown  in  Tables  5  and  6,  would  be  as  is  shown  in  Table  7  because  a 
Cessna  172  aircraft  has: 
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•  No  weapons  therefore  support  for  transmission  of  the  Fire  and  Detonation  PDUs  is  not 
required.  However  support  for  the  reception  of  Detonation  PDUs  is  (may  be)  required 
to  determine  any  damage  resulting  from  the  detonation  of  a  weapon  -  see  below; 

•  No  radar  sensor  system  therefore  support  for  the  Electromagnetic  Emission  PDU  is  not 
required;  and 

•  No  tactical  data  link  system  therefore  support  for  the  SISO-J  capability  of  the 
Transmitter  and  Signal  PDUs  is  not  required. 


Figure  6  A  Cessna  172  Skyhawk  aircraft  which  is  used  by  some  Military  Forces 

The  DIS  PDUs  that  should  be  supported  in  a  Cessna  172  LVC  system  that  comply  with  the 
ADF  Corporate  Synthetic  Range  Interoperability  Model  are  shown  in  Table  7. 

As  long  as  the  high-fidelity  LVC  system  for  the  Cessna  172  "Skyhawk"  aircraft  supports 
appropriate  interoperability  for  the  Entity  State,  IFF,  Transmitter  and  Signal  PDUs,  it  would 
be  considered  as  being  compliant  with  the  Synthetic  Range  Interoperability  Model  as 
described  in  Tables  5  and  6. 

However,  any  system  that  has  weapons,  a  sensor  system,  radio  communications  and  a  Link-16 
tactical  data  link  capability  should  support  all  the  DIS  PDUs  (or  their  HLA  RPR-FOM 
equivalents)  as  shown  in  Tables  5  and  6. 

A  Cessna  172  does  not  (normally)  carry  any  weapons  and  would  therefore  not  need  to 
transmit  any  Fire  and  Detonation  DIS  PDUs  into  the  distributed  simulation  network. 
However  in  DIS  it  is  the  responsibility  of  every  DIS  system  to  determine  if  any  exploding 
weapons  have  any  effect  on  their  ownship  system.  Therefore  all  DIS  LVC  systems  (including 
our  Cessna  172  LVC  system)  must  (should)  be  able  to  detect  a  Detonation  PDU  and  determine 
if  there  would  be  any  damage  to  the  ownship  system  (our  Cessna  172  LVC  system)  by 
examining  the  data  from  the  Detonation  PDU. 

If  our  Cessna  172  LVC  system  did  not  support  this  capability  a  direct  hit  with  a  virtual 
weapon  (eg  missile)  would  have  no  effect! 
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9.6  Section  Summary 

Interoperability  between  LVC  systems  within  a  common  scenario  requires  compliance  with  an 
agreed  set  of  interoperability  standards  including  network  infrastructure,  data, 
interoperability  protocols,  platform  /  environmental  representation,  etc.  This  requires  the 
development  of  a  Synthetic  Range  Interoperability  Model  (a  set  of  interoperability  standards) 
that  is  a  crucial  part  of  any  synthetic  range  architecture.  All  synthetic  range  systems  that  are 
compliant  with  a  particular  (ie  corporate  ADF)  Synthetic  Range  Interoperability  Model  should 
be  highly  interoperable  (with  each  other)  regardless  of  whether  the  systems  are  Live,  Virtual 
or  Constructive. 


Table  7  Synthetic  Range  Interoperability  Model  Compliance  Requirement  for  a  Cessna  172  aircraft. 


Synthetic  Range  Interoperability  Model  Compliance  Requirement  for  a  Cessna 

172 

DIS  PDUs 

Data  Functionality 

Entity  State  PDU 

Entity  Information 

Fire  PDU 

No  Weapons  Capability  -  not  required 

Detonation  PDU 

Receive  Only  Detonation  PDU  to  Determine 
Ownship  Damage 

Electromagnetic  Emission  PDU 

No  Sensor  System  Capability  -  not  required 

IFF  PDU 

IFF  Information 

Transmitter  PDU 

Radio  Communications  Information 

Signal  PDU 

Radio  Communications  Information 

Transmitter  PDU  (SISO-J) 

No  Tactical  Data  Link  interoperability  -  not 
required 

Signal  PDU  (SISO-J) 

No  Tactical  Data  Link  interoperability  -  not 
required 

This  "Standards  Based  Approach"  architecture  will  provide  a  high-reliability,  routine,  robust, 
scalable  and  reliable,  global,  LVC,  daily  training  capability  for  the  war-fighter.  The  USAF 
Distributed  Mission  Operations  (DMO)  capability  is  based  on  this  standards  based  approach 
philosophy  [Aldinger], 

All  specifications  defined  in  a  Synthetic  Range  Interoperability  Model  must  be  mandated! 

Once  a  Synthetic  Range  Interoperability  Model  (ie  interoperability  standards)  has  been 
precisely  and  unambiguously  defined,  common  RFT  specifications  and  test  and  acceptance 
procedures  to  enable  accreditation  for  that  particular  Synthetic  Range  Interoperability  Model 
can  be  developed. 

LVC  systems  cannot  participate  in  exercises  unless  appropriate  accreditation  has  occurred. 
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Compliance  with  a  Synthetic  Range  Interoperability  Model  does  not  restrict  additional 
enhancements  for  specific  LVC  systems. 


10.  How  Do  We  Precisely  and  Unambiguously  Define 
What  Needs  to  be  Defined  in  a  Corporate 
Interoperability  Standard? 

10.1  Mandated  DIS  PDUs 

Tables  3,  5  and  6  specify  recommended  ADF  LVC  and  VC  Synthetic  Range  Interoperability 
Models  at  the  DIS  PDU  level.  These  tables  specify  which  DIS  PDUs  all  compliant  systems 
must  support  (subject  to  the  discussion  in  section  9.4).  Support  for  all  specified  PDUs  included 
in  the  Synthetic  Range  Interoperability  Model  must  be  mandated  otherwise  support  for  every 
PDU  is  not  precisely  and  unambiguously  determined. 

Although  defining  specifically  which  DIS  PDUs  each  LVC  system  must  support  is  beginning 
to  precisely  and  unambiguously  define  what  information  each  LVC  system  needs  to 
disseminate  and  know  about,  defining  an  interoperability  model  at  the  PDU  level  is  not 
sufficient.  It  is  however  starting  to  move  from  a  reducing  risk  approach  towards  a 
guaranteeing  interoperability  approach.  However  it  still  does  not  precisely  and 
unambiguously  define  the  required  LVC  system  data! 


10.2  Mandated  DIS  PDU  Data  Fields 

For  each  DIS  PDU  specified  in  an  ADF  Synthetic  Range  Interoperability  Model,  mandatory 
fields  within  each  specified  PDU  must  also  be  specified.  This  indicates  to  every  Synthetic 
Range  Interoperability  Model  compliant  LVC  system  which  fields  in  which  DIS  PDUs  must  be 
precisely  and  unambiguously  populated  with  standardised  data. 

Compliant  systems  must  interoperate  appropriately  (ie  correctly)  with  appropriately  specified 
data  in  these  specified  and  mandated  DIS  PDUs  and  DIS  PDU  data  fields. 

Compliant  systems  must  appropriately  (ie  correctly)  populate  the  specified  and  mandated  DIS 
PDU  fields  with  appropriately  specified  data  when  transmitting  the  specified  DIS  PDUs  into 
the  distributed  simulation  network. 

However  when  receiving  DIS  PDUs,  compliant  systems  will  then  also  unambiguously  and 
precisely  understand  the  meaning  of  (ie  understand  how  to  appropriately  interoperate  with) 
appropriately  specified  data  detected  in  the  specified  and  mandated  DIS  PDU  fields. 

The  structure  and  the  format  of  each  DIS  PDU,  and  each  data  field  within  the  specific  DIS 
PDU,  is  defined  by  the  appropriate  IEEE  DIS  Standard  [DIS  (1995)],  [DIS  (1998)]. 
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A  Synthetic  Range  Interoperability  Model  would  define  (ie  document)  which  DIS  PDUs  are 
mandated  and  need  to  be  supported  -  as  in  Tables  3,  5  and  6. 

A  Synthetic  Range  Interoperability  Model  would  also  define  which  PDU  data  fields  must  be 
mandated  for  each  mandated  DIS  PDU. 

Table  8  shows  the  format  of  some  of  the  data  fields  contained  in  the  DIS  Entity  State  PDU  as 
specified  in  the  appropriate  IEEE  DIS  Standard  [DIS  (1995)]. 

The  Entity  State  Protocol  Data  Unit  (PDU)  exists  to  communicate  information  about  an 
entity's  state  so  that  a  receiving  simulation  application  can  appropriately  represent  the  entity 
within  the  simulation  application.  Defining  what  entity  is  being  represented  by  the  Entity 
State  PDU  is  a  fundamental  objective  of  the  Entity  State  PDU  [DIS  (1995)]. 

The  type  of  entity  described  in  a  DIS  Entity  State  PDU  is  described  by  the  data  found  in  the 
Entity  Type  record  contained  within  it  [DIS  (1995)]  -  bottom  of  Table  8.  The  fields  found  in  the 
Entity  Type  record  are  as  follows: 


Table  8  Format  of  Some  of  the  Data  Fields  in  the  DIS  Entity  State  PDU. 


Field  size 
(bits) 

Entity  State  PDU  fields 

96 

PDU  Header 

Protocol  Version— 8-bit  enumeration 

Exercise  ID— 8-bit  unsigned  integer 

PDU  Type— 8-bit  enumeration 

Protocol  Family— 8 -bit  enumeration 

Timestamp— 32-bit  unsigned  integer 

Length— 16-bit  unsigned  integer 

Padding  — 16  bits  unused 

48 

Entity  ID 

Site  —  16-bit  unsigned  integer 

Application  —  16-bit  unsigned  integer 

Entity  —  16-bit  unsigned  integer 

8 

Force  ID 

8-bit  enumeration 

8 

Number  of  Articulation 
Parameters  (n) 

8-bit  unsigned  integer 

64 

Entity  Type 

Entity  Kind— 8-bit  enumeration 

Domain— 8-bit  enumeration 

Country  —  16-bit  enumeration 

Category— 8-bit  enumeration 

Subcategory — 8-bit  enumeration 

Specific— 8-bit  enumeration 

Extra— 8-bit  enumeration 
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•  Entity  Kind:  identifies  the  kind  of  entity  such  as  a  platform,  a  munition,  a  life  form,  etc.; 

•  Domain:  specifies  the  domain  in  which  the  entity  operates.  For  platform  entities  the  set 
of  entity  domains  are  other,  land,  air,  surface,  subsurface  and  space.  Domains  depend 
on  the  entity  kind; 

•  Country:  specifies  the  country  to  which  the  design  of  the  entity  is  attributed.  For 
example  the  country  code  of  the  US  used  in  this  field  is  225,  the  country  code  for 
Australia  is  13; 

•  Category:  specifies  the  main  category  that  describes  the  entity.  Some  examples  of 
categories  for  the  air  domain  are  Fighter/ Air  Defence,  Attack/ Strike,  Bomber,  etc.; 

•  Subcategory:  specifies  a  particular  subcategory  to  which  an  entity  belongs  based  on  the 
Category  field.  Some  examples  here  for  an  Air  Domain  Fighter/ Air  Defence  Category 
are  F-16,  F-15,  F-22,  F/A-18,  etc.; 

•  Specific:  Further  defines  specific  information  about  a  Subcategory  entity  such  as  an 
F/A-18A,  an  F/A-18B,  etc.;  and 

•  Extra:  contains  extra  information  to  describe  a  particular  entity. 

The  entity  information  is  usually  presented  in  the  numeric  form  Kind  :  Domain  :  Country  : 
Category :  Subcategory :  Specific :  Extra  where  the  enumeration  1:2:225:1:9:1:0  (or  1:2:225:1:9:1) 
represents  a  USA  designed,  F/A-18A  aircraft. 

Mandating  DIS  PDU  data  fields  indicates  to  compliant  systems  that  (some  of)  the  data  present 
in  these  fields  will  be  precisely  and  unambiguously  known  or  defined.  It  will  then  be  the 
responsibility  of  compliant  LVC  systems  to  appropriately  interoperate  with  that  data  found  in 
these  mandated  DIS  PDU  data  fields. 


10.3  Mandated  DIS  PDU  Data  Field  Enumerations  Data 

The  actual  data  contained  within  the  DIS  PDU  data  fields  are  known  as  enumerations  and  can 
be  found  in  a  SISO  standard  titled  "Enumeration  and  Bit  Encoded  Values  for  Use  with 
Protocols  for  Distributed  Interactive  Simulation  (ie  DIS)  Applications"  [SISO-REF-010].  The 
latest  version  of  this  standard  is  always  available  from  www.sisostds.org. 

A  set  of  standard  enumerations  (from  the  SISO-REF-OIO  document)  that  will  define  a 
minimum  known  set  of  enumerations  data  for  every  mandated  DIS  PDU  data  field  in  every 
mandated  DIS  PDU  must  still  be  defined! 

When  an  enumeration  is  specified  for  an  LVC  system,  that  LVC  system  may  have  to  have  a 
visual  database  model  developed,  a  behavioural  model  developed,  a  sensor  model  developed, 
etc.  It  can  add  considerable  cost  to  support  specific  enumerations  -  especially  after  the  LVC 
system  has  been  accepted  by  the  Commonwealth.  This  is  why  a  common  ADF  corporate 
standard  enumerations  set,  (pre-)  defined  at  tender  specification  time  for  all  ADF  LVC 
systems,  should  reduce  cost  because  all  compliant  ADF  LVC  systems  will  be  interoperable 
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with  the  standard  enumerations  set  at  delivery  ie  "Out-Of-The-Box"!  Some  standard 
enumeration  set  data  (eg  a  visual  model  of  an  ADF  F /  A-18)  may  be  reusable  between 
compliant  LVC  systems. 

However  not  all  enumeration  data  that  will  be  found  in  the  standardised  DIS  PDU  data  fields 
will  be  included  in  the  standard  ADF  Corporate  Enumerations  set  as  this  would  force  all 
compliant  LVC  systems  to  support  enumerations  that  may  only  be  of  interest  to  a  small  group 
or  number  of  LVC  systems.  If  such  enumerations  were  to  be  included  in  an  ADF  Corporate 
Standard  Enumerations  Set  this  would  most  likely  add  considerable,  unnecessary  cost  as  most 
compliant  LVC  systems  may  never  require  the  use  of  such  enumerations  but  a  visual  database 
model  may  have  to  be  developed,  a  behavioural  model  may  have  to  be  developed,  a  sensor 
model  may  have  to  be  developed,  etc.  for  every  enumeration  for  every  compliant  LVC 
systems.  The  standard  ADF  Corporate  Enumerations  set  must  be  well  thought  out  and  as  long 
as  all  Joint  and  Coalition  scenarios  use  enumerations  from  this  standard  ADF  Corporate 
Enumerations  set,  "Out-Of-The-Box"  interoperability  should  be  very  high! 

Therefore  the  ADF  Corporate  Synthetic  Range  Interoperability  Model  will  contain 
documentation  that  defines  what  DIS  PDUs  must  be  mandated,  what  DIS  PDU  data  fields 
must  be  mandated  for  each  mandated  DIS  PDU  (eg  the  Entity  State  PDU  Entity  Type  record 
data  fields),  and  it  will  also  contain  a  standard  set  of  ADF  Corporate  Synthetic  Range 
Interoperability  Model  enumerations  that  define  exactly  what  mandated  standard 
enumeration  data  may  be  found  in  the  mandated  DIS  PDU  data  fields. 

The  PDUs,  PDU  data  fields,  and  the  standard  set  of  ADF  Corporate  Synthetic  Range 
Interoperability  Model  enumerations  must  be  mandated  for  all  compliant  LVC  systems 
otherwise  a  high  level  of  "Out-Of-The-Box"  interoperability  cannot  be  guaranteed.  In  the 
USAF  DMO  system,  LVC  systems  cannot  begin  network  integration  activities  (ie  join  the 
DMO  network  to  participate  in  a  distributed  exercise)  unless  the  systems  have  been  accredited 
-  that  is  they  have  been  tested  and  certified  as  being  compliant  with  all  the  required  DMO 
interoperability  standards. 


10.4  Section  Summary 

All  relevant  Synthetic  Range  Interoperability  Model  parameters  (eg  DIS  PDUs,  DIS  PDU  data 
fields  (or  their  HLA  equivalents),  enumerations  and  any  other  relevant  parameters  must  all  be 
mandated  for  "Out-The-Box"  interoperability  to  be  maximised. 


11.  How  Does  DSTO  Proceed  From  Here? 


The  USA  DoD  LVCAR  Study  fundamental  precept  #4  (section  4.3)  suggests  that  a  centralised 
management  team  (which  is  corporately  funded)  is  necessary  to  prevent  divergence;  to  enable 
the  architecture  convergence  strategy;  and  to  have  influence  on  future  LVC  architecture 
development  activities  (ie  the  development  of  corporate  interoperability  standards),  via 
funding  decisions,  on  the  organisations  that  evolve  existing  architectures.  Without  such 
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centralised  management  and  funding,  existing  architecture  communities  (eg  DSTO  Divisional 
communities)  will  continue  to  operate  in  line  with  their  own  self-interests,  and  the  broader 
corporate  LVC  interoperability  needs  of  the  organisation  (eg  DSTO)  will  be  treated  as 
secondary  issues,  that  are  likely  to  continue  to  be  ignored  as  concerns  that  are  not  relevant  to 
higher  priority,  locally  funded  problems.  Unless  corporate  interoperability  development  work 
is  centrally  managed  (ie  tasked  and  resourced),  corporate  interoperability  development  may 
not  occur,  or  if  it  did,  it  would  only  occur  in  an  unsatisfactory  ad-hoc  fashion  (section  5.3.4). 

The  LVCAR  Study  fundamental  precept  #2  (section  4.3)  states  that  interoperability  is  not  free  - 
it  needs  to  be  appropriately  resourced.  It  may  be  difficult  to  justify  and  accurately  quantify  a 
return  on  investment  in  LVC  interoperability  however  it  is  also  unreasonable  to  expect  that 
LVC  interoperability  can  be  achieved  with  little  or  no  investment. 

Therefore  the  LVCAR  Study  fundamental  precepts  2  and  4  infer  that  interoperability  work 
should  be  centrally  managed  and  appropriately  funded. 

In  AOD  there  are  two  programmes  of  work  that  could,  and  already  do  to  some  extent  (eg  this 
report),  contribute  to  the  development  of  ADF  corporate  interoperability  standards:  the 
proposed  AOD  (USAF)  DMO  compliant.  Mission  Training  Centre  (MTC),  Capability  Concept 
Demonstrator  (CCD)  [Zalcman  (2010)];  and  the  DSTO  Net  Warrior  initiative  [Filippidis] . 


11.1  An  AOD  Mission  Training  Centre  Capability  Concept  Demonstrator 

A  (USAF)  DMO  compliant.  Mission  Training  Centre  (MTC),  Capability  Concept  Demonstrator 
(CCD),  to  be  developed  by  AOD,  has  been  proposed  [Zalcman  (2010)]. 

The  DSTO  Air  Operations  Division  has  sufficient  simulation  system  components,  expertise 
and  experience  to  develop  such  a  DMO  compliant  MTC  CCD,  similar  to  that  developed  by  the 
UK  MOD  MTDS  (Mission  Training  through  Distributed  Simulation)  programme  [Khetia]. 

The  objectives  of  this  AOD  MTC  CCD  will  be: 

•  To  study  various  elements  of  Joint  and  Coalition  synthetic  Live-Virtual-Constructive 
(LVC)  training  to  provide  guidance  on  technical  and  operational  issues  to  assist  the 
RAAF  to  migrate  towards  a  highly  interoperable,  LVC  corporate  synthetic  environment 
(Synthetic  Range)  to  enable  a  training  focused,  DMO  compliant  RAAF  MTC  proposal  to 
be  developed; 

•  To  do  experimentation,  research  and  development  to  help  the  ADF  and  RAAF  develop 
corporate  interoperability  standards  based  on  the  USAF  DMO  standards.  These 
standards,  to  be  known  collectively  as  the  ADF  Corporate  Synthetic  Range 
Interoperability  Model,  will  form  the  advanced  distributed  simulation  infrastructure 
(i.e.  the  standards  based  approach)  upon  which  the  AOD  MTC  CCD  (and  therefore  the 
RAAF  MTC)  will  be  developed.  The  objective  of  this  work  is  to  reduce  risk  and  cost 
when  acquiring  future  corporate  ADF  LVC  components,  training  systems  and 
operational  platforms  with  LVC  capabilities;  and 

•  To  test,  evaluate  and/or  develop  re-usable  LVC  components  (Blue,  Red  and  White 
Forces  CGF  applications.  Loggers,  After- Action-Review  applications,  etc)  which  could 
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be  used  (and  re-used)  to  reduce  cost  and  risk  for  current  and  future  ADF  and  RAAF 
operational  platforms,  and  training  and  experimentation  systems  with  LVC  interfaces. 

Some  sample  NATO  "Use  Cases"  involving  LVC  systems  given  to  illustrate  the  importance  of 
integrating  Live  Simulation  (section  2.3.4)  in  both  training  and  simulation  environments 
[Gustavsson]  include: 

•  Extended  Air  Defence  Simulation  -  Several  types  of  real  operational  sensors  (radar) 
airborne/ ground-based  Air  Defence  systems  fed  with  a  synthetic  environment 
including  aircraft  and  ballistic  and  cruise  missiles; 

•  Composite  Air  Operations  -  Large  numbers  of  aircraft  and  air/  ground  defence  to  be 
able  to  attack  certain  targets.  In  the  future  this  could  include  live  aircraft  and  sensors 
including  AWACS  with  real  pilots/ real  operators; 

•  Close  Air  Support/ Indirect  Fire  Support  -  Training  of  the  Forward  Air  Controller/ 
Forward  part  in  a  live  environment;  and 

•  Training  In  Real  C2  System  Environments  -  In  many  training  and  simulation  systems 
where  real  operational  C2-systems  interoperate  with  other  live  operational  systems. 

RAAF  Air  Battle  Management  (ABM)  teams  are  responsible  for  the  tactical  command  and 
control  of  all  air  assets  in  the  battlespace  and  are  typically  comprised  of  a  Tactical  Director  and 
a  number  of  Fighter  Controllers.  The  Tactical  Director  allocates  assets  and  manages  operations 
within  the  air  battle,  overseeing  and  directing  the  Fighter  Controllers,  and  communicates  with 
other  command  elements  and  external  agencies.  The  Fighter  Controllers  liaise  with  pilots  in 
order  to  direct  aircraft  in  accordance  with  instructions,  procedures,  the  tactical  plan,  and  as 
directed  by  the  Tactical  Director  [Shanahan], 

Some  AOD  simulation  systems  that  could  support  the  above  example  Use  Cases  and  could 
form  the  basis  of  a  DMO  compliant,  AOD  Air  Battle  Management,  MTC  CCD  include: 

•  A  Ground  Based  Air  Defence  system  -  The  Air  Defence  Ground  Environment 
SIMulator  (ADGESIM)  is  the  actual  high-fidelity  training  system  (ie  it  stimulates  the 
real,  operational  software  used  by  the  RAAF)  used  to  train  RAAF  Air  Combat  Officers 
(developed  at  DSTO); 

•  A  Fighter  Aircraft  system  -  The  Deployable  Aircraft  Cockpit  Simulator  (DACS)  is  being 
developed  at  the  AOD  Air  Operations  Simulation  Centre  (AOSC);  and 

•  An  Airborne  Early  Warning  &  Control  (AEW&C)  aircraft  (AWACS  like  aircraft  referred 
to  as  Wedgetail)  system  -  The  Wedgetail  Integration  and  Research  Environment 
(WIRE)  is  a  high-fidelity  representation  (it  is  a  stimulated,  real  operational  AEW&C 
mission  software  system)  of  the  user  interface  used  in  the  real  RAAF  AEW&C  aircraft. 

An  AOD,  Air  Battle  Management,  Mission  Training  Centre  Task  should  be  developed  within 
AOD  as  the  ADGESIM,  DACS  and  AEW&C  WIRE  systems  are  all  AOD  systems.  One  of  the 
problems  with  Net  Warrior  is  that  inter-Divisional  LVC  simulation  systems  interoperability  is 
not  directly  funded  and  neither  is  it  high  priority  for  individual  DSTO  Divisions.  Inter- 
Divisional  LVC  simulation  system  interoperability  is  generally  treated  as  low  priority  and  this 
impedes  (LVC  interoperability)  progress  considerably  -  this  is  why  it  is  important  (and  also 
very  convenient)  that  the  systems  under  development  in  the  AOD  MTC  CCD  proposal  are  all 
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managed  and  funded  by  AOD  (see  section  5.3.4)  thus  learning  the  lessons  as  described  by  the 
LVCAR  Study  precept  #  4  (sections  4.3.4  and  5.3.4). 

The  first  step  to  building  such  a  capability  is  to  further  develop  an  appropriate  ADF  Corporate 
Synthetic  Range  Interoperability  Model  (ie  the  required  interoperability  standards)  and  to 
then  develop  the  AOD  ADGESIM,  DACS  and  the  AEW&C  WIRE  systems  to  be  compliant 
with  this  Synthetic  Range  Interoperability  Model  ie  to  be  LVC  interoperable. 

These  AOD  systems  can  then  be  connected  over  the  persistent,  classified  (DSTO  Net  Warrior) 
network  that  has  already  been  (or  will  shortly  be)  developed  as  part  of  the  Net  Warrior 
initiative  [Foster],  [Sioutis]. 

It  is  the  intention  of  the  authors  of  this  report  to  produce  a  DSTO  Report  on  the  development 
of  an  AOD  Air  Battle  Management  Mission  Training  Centre  in  the  near  future. 


11.2  The  DSTO  (AOD)  Net  Warrior  Initiative 

The  DSTO  Net  Warrior  initiative  was  conceived  to  address,  through  experimentation,  new 
and  evolving  network  centric  capabilities  and  mission  system  technologies  to  enhance  ADF 
joint  war  fighting  capabilities  [Foster],  [Sioutis] .  With  this  as  the  prime  objective.  Net  Warrior 
will  be  in  part  the  realisation  of  a  general  ambition  in  DSTO  to  create  a  research  network  of 
(NCW  enabled)  Battlelabs  [Filippidis]. 

Initially,  the  Net  Warrior  initiative  has  developed  a  persistent  network  infrastructure  to 
support  a  research  capability  in  NCW  by  connecting  a  set  of  nodes  which  are  test-beds 
representing  current  or  potential  future  ADF  assets  [Lawrie],  [Zalcman  (2006)],  [Zalcman 
(2007)],  [Zalcman  (2008)]. 

The  nodes  were  selected  using  the  criteria  of: 

•  The  need  for  interoperability  of  the  real  assets; 

•  The  significance  of  the  real  assets  in  joint  operations; 

•  Whether  high  fidelity  representations  of  the  assets  exist  or  are  planned  in  DSTO;  and 

•  Whether  experimental  representations  of  potential  assets  would  benefit  from 
participating. 

High  fidelity  test-beds  allow  evaluation  of  real  systems  and  investigation  of  relevant  technical 
and  operational  issues.  The  DSTO  nodes  will  be  high  fidelity  representations  of  airborne  and 
maritime  assets  and  will  include  AEW&C,  ADGE  and  a  future  ship.  These  nodes  already 
exist,  in  some  form,  but  at  present  are  not  able  to  appropriately  interoperate  with  each  other. 

Net  Warrior  interoperability  standards  do  not  currently  exist.  This  current  report  is  part  of  the 
work  to  develop  such  Net  Warrior  interoperability  standards. 

The  test-beds  will  evolve  in  themselves  as  integral  components  of  the  Net  Warrior  network 
and  as  stand-alone  components  of  research  capabilities  with  platform  centric  research 
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objectives.  Where  there  is  common  interest,  exercises  will  be  run  which  involve  all  nodes  or  a 
subset  of  these  nodes. 

The  Air  Defence  Ground  Environment  SIMulator  (ADGESIM)  [Blacklock  (2006)],  [Blacklock 
(2007)],  [Zalcman  (2005)],  [Zalcman  (2006)],  [Zalcman  (2008)],  [Zalcman  (2009)  - 1],  [Zalcman 
(2009)  -  2]  the  Deployable  Aircraft  (i.e.  F/A-18)  Cockpit  Simulator  (DACS)  systems,  and  the 
AEW&C  High-Fidelity  WIRE  (Wedgetail  Integration  and  Research  Environment)  simulation 
system  are  all  being  developed  and/or  deployed  within  DSTO's  Air  Operations  Division. 
Multiple  instances  of  ADGESIM  and  the  WIRE  already  exist  in  branches  of  AOD. 

Both  the  ADGESIM  and  WIRE  systems  are  based  on  real  operational  components  -  they  are 
high  fidelity,  stimulated  systems. 

The  ADGESIM  (Air  Combat  Officer)  simulation  system  (which  is  used  by  the  RAAF  to  train 
RAAF  Air  Combat  Officers  -  see  Figure  4)  is  fully  compliant  with  the  (proposed)  ADF 
Corporate  Synthetic  Range  Interoperability  Model  shown  in  Table  3  -  at  least  down  to  the 
PDU  level. 

The  DACS  and  WIRE  systems  are  also  being  continuously  developed  towards  being 
compliant  with  the  Table  3  Synthetic  Range  Interoperability  Model.  An  objective  of  Net 
Warrior  is  to  support  USAF  DMO  compliant  interoperability.  The  development  of  such  a  set 
of  DMO  compliant  interoperability  standards  will  accelerate  the  development  of  coalition 
DMO  compliance  for  the  DACS  and  WIRE  systems. 

Once  these  DSTO  AOD  simulation  systems  are  all  compliant  with  such  a  set  of  appropriate 
interoperability  standards  (eg  a  Net  Warrior  Synthetic  Range  Interoperability  Model)  the 
AOD  ADGESIM,  DACS  and  WIRE  (LVC)  systems  should  all  be  highly  interoperable  with 
each  other  and  with  other  similarly  compliant  LVC  systems. 

Since  it  is  assumed  that  the  Synthetic  Range  Interoperability  Model  defines  a  set  of 
(distributed  simulation,  radio  communications  and  tactical  data  link)  interoperability 
standards  that  should  be  very  similar  to  the  interoperability  standards  used  by  the  USAF 
DMO  Program,  systems  that  are  compliant  with  the  recommended  ADF  Corporate  Synthetic 
Range  Interoperability  Model  (and  the  Net  Warrior  Synthetic  Range  Interoperability  Model) 
should  then  also  be  highly  interoperable  with  USAF  DMO  compliant  simulation  systems. 

The  DSTO  Net  Warrior  initiative  is  currently  managed  by  AOD.  DSTO  LVC  systems  from 
other  DSTO  Divisions  also  participate  in  Net  Warrior  activities.  However  Net  Warrior  is  not  a 
task  and  does  not  have  any  direct  control  of  any  resources  (manpower  or  funding)  of  its  own. 
Net  Warrior  activities  are  resourced  by  voluntary  contributions  from  individual  DSTO 
Divisional  tasks. 

Discussions  are  now  occurring  to  progress  Net  Warrior  towards  becoming  a  multi-Divisional 
DSTO  task  sponsored  by  multiple  sponsors. 

11.3  Moving  Forward 

Both  the  proposed  AOD  MTC  CCD  and  Net  Warrior  programmes  should  be  natural  sponsors, 
developers,  consumers  and  testers  of  the  DSTO  developed  corporate  LVC  interoperability 
standards. 
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All  AOD  MTC  CCD  and  Net  Warrior  LVC  systems  should  be  compliant  with  AOD  developed 
Corporate  LVC  interoperability  standards.  As  soon  as  these  interoperability  standards  have 
been  developed  a  set  of  Test  and  Acceptance  (T&A)  compliance  procedures,  which  should  be 
considered  as  part  of  the  AOD  Corporate,  LVC,  Synthetic  Range  Interoperability  Model, 
should  also  be  developed. 

The  AOD  developed  ADGESIM  and  DACS  systems  may  already  be  fully  compliant  with  the 
Synthetic  Range  Interoperability  Model  shown  in  Table  3  -  certainly  at  the  DIS  PDU  level. 
Once  the  AOD  Corporate,  Test  and  Acceptance  (T&A)  compliance  procedures  have  been 
developed  the  ADGESIM  and  DACS  systems  should  be  "tested  and  accepted"  (ie  accredited) 
against  the  AOD  Corporate,  LVC  interoperability  standards. 

Initial  testing  may  require  modification  of  some  of  the  interoperability  standards  which  will 
then  require  modification  of  the  corresponding  T&A  procedures,  etc.  The  interoperability 
standards  and  the  corresponding  T&A  procedures  would  need  to  be  reviewed,  and  possibly 
amended,  regularly.  However  when  all  the  required  interoperability  standards,  and  their 
corresponding  T&A  procedures,  become  stable  they  can  be  turned  into  RFT  specifications  by 
appropriate  ADF  acquisition  staff  (eg  DMO  or  Directorate  Aerospace  Simulators  and  Special 
Purpose  Aircraft)  and  eventually  be  used  when  specifying  ADF  systems  requiring  LVC 
interoperability.  This  acquisition  process  is  an  additional  process  that  assists  moving  from 
reducing  risk  towards  guaranteeing  interoperability  for  acquired  ADF  LVC  systems. 


11.4  Section  Summary 

According  to  the  LVCAR  Study  precepts  2  and  4  interoperability  work  should  be  centrally 
managed  and  appropriately  funded  to  prevent  divergence,  and  to  influence  LVC  architecture 
development  activities,  via  funding  decisions,  on  the  organisations  that  evolve  existing 
architectures.  Otherwise  existing  architecture  communities  will  operate  in  line  with  their  own 
self-interests;  the  broader  corporate  LVC  interoperability  needs  of  the  organisation  will  be 
treated  as  secondary  issues  that  are  likely  to  continue  to  be  ignored  as  concerns  that  are  not 
relevant  to  higher  priority,  locally  funded  problems;  and  corporate  interoperability 
development  may  only  occur,  if  at  all,  in  an  unsatisfactory  ad-hoc  fashion. 

In  AOD  the  proposed  AOD  DMO  compliant.  Mission  Training  Centre,  Capability  Concept 
Demonstrator  [Zalcman  (2010)],  comprising  the  AOD  ADGESIM,  DACS  and  AEW&C  WIRE 
systems,  and  the  DSTO  Net  Warrior  initiative  [Filippidis]  could  both  contribute  to  the 
development  of  ADF/RAAF  corporate  interoperability  standards. 

However  both  these  programmes  must  be  appropriately  resourced  and  funded  (as  DSTO 
tasks),  and  corporate  interoperability  must  be  made  a  high  priority. 

Both  programmes  (ie  DSTO  Tasks)  would  be  natural  sponsors,  developers,  consumers  and 
testers  of  the  DSTO  developed.  Corporate  LVC  interoperability  standards  arising  from  their 
work. 

The  AOD  developed  ADGESIM  and  DACS  systems  may  already  be  fully  compliant  with  the 
recommended  corporate  ADF  Synthetic  Range  Interoperability  Model  -  certainly  at  the  DIS 
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PDU  level.  The  AEW&C  WIRE  system  is  currently  being  analysed  to  see  if  it  can  be  made 
compliant  with  the  recommended  corporate  ADF  Synthetic  Range  Interoperability  Model. 

Once  an  appropriate  set  of  corporate  LVC  interoperability  standards  has  been  developed,  a 
corresponding  set  of  Test  and  Acceptance  (T&A)  compliance  procedures  will  also  need  to  be 
developed.  The  ADGESIM  and  DACS  systems  should  then  be  "tested  and  accepted"  (ie 
accredited)  against  the  AOD  Corporate,  LVC  interoperability  standards  using  the  developed 
Test  and  Acceptance  (T&A)  compliance  procedures. 

Experimental  exercises  should  be  carried  out  using  accredited  systems  to  see  if 
interoperability  problems  are  reduced.  This  interoperability  standards  development  cycle 
should  continue  until  a  "stable  level"  of  interoperability  has  been  achieved. 

A  set  of  RFT  specifications,  that  could  be  used  to  specify  ADF  systems  requiring  LVC 
interoperability,  could  then  be  developed.  This  process  would  then  hopefully  move  the  ADF 
from  reducing  risk  towards  guaranteeing  interoperability  for  acquired  ADF  LVC  systems. 


12.  Conclusions 


Integrating  the  lessons  learned  and  the  recommendations  from  the  recently  released  US  DoD 
LVCAR  Study  [LVCAR  -  1],  [LVCAR  -  2]  with  work  already  done  [Zalcman  (2010)]  in  the 
development  of  the  Concept  of  the  Synthetic  Range  and  its  associated  Synthetic  Range 
Interoperability  Model,  has  enabled  an  (ie  this)  ADF  LVC  interoperability  strategy  to  be 
developed. 

The  Live-Virtual-Constructive  Architecture  Roadmap  (LVCAR)  is  intended  to  guide  actions 
and  decision-making  on  the  development,  employment  and  integration  of  US  DoD  LVC 
environments  and  architectures  over  the  next  10  years. 

The  purpose  of  the  LVCAR  Study  (phase  1  of  the  LVCAR)  was  to  develop  a  future  vision  and 
supporting  strategy  to  achieve  significant  interoperability  improvements  in  LVC  simulation 
environments. 

To  support  the  implementation  of  this  strategy  the  LVCAR  study  specifies  near-,  mid-,  and 
long-term  actions  that  collectively  delineate  a  roadmap  that  begins  to  guide  the  evolution 
from  the  current  state  of  LVC  environment  development  to  achieve  the  desired  future  vision. 
However  in  such  a  complex  environment,  mid-course  adjustments  would  be  expected. 

The  US  DoD  LVCAR  Study  activities  are  designed  to  enhance  interoperability  in  a  mixed- 
architecture  environment,  while  preserving  options  and  positioning  the  community  for  some 
degree  of  architecture  convergence  in  the  future.  These  activities  are  founded  on  the  idea  that 
having  multiple  architectures  available  for  use  is  desirable  and  that  the  best  way  forward  is  to 
take  actions  that  can  reduce  or  eliminate  the  barriers  to  interoperability  between  the  existing 
architectures  and  protocols. 

More  specifically,  this  strategy  acknowledges  that  existing  architectures  have  been  created, 
have  evolved,  and  are  being  maintained  to  meet  the  specific  needs  of  their  constituent 
communities.  Elimination  of  any  architecture  should  only  occur  as  a  natural  result  of  disuse. 
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Modification  and  management  of  the  existing  architectures  is  left  to  the  owning  communities 
as  the  best  option  to  ensure  meeting  the  needs  of  the  various  user  communities,  both 
throughout  the  DoD  and  amongst  coalition  partners.  To  resolve  interoperability  problems, 
efforts  should  be  directed  towards  creating  and  providing  standard  resources,  such  as 
common  gateways  and  tools,  common  componentised  object  models,  and  common  federation 
agreements.  These  can  resolve  the  problems  identified  and  render  integration  of  the  multiple 
architectures  an  efficient  and  nearly  transparent  process  by  creating  the  perception  of  a  single 
architecture  that  supports  all  of  the  diverse  simulation  systems.  Thus,  the  systems  will 
actually  be  serviced  by  an  "architecture  of  architectures",  comprised  of  as  many  different 
architectures  and  protocols  as  are  required  to  interconnect  the  participating  simulation 
systems. 

The  presence  of  multiple  protocols/ architectures  and  the  (incorrect)  perception  that 
interoperability  would  be  much  easier  (and  less  costly)  if  only  a  single  architecture  were 
available  has  been  discussed. 

The  four  fundamental  precepts  (core  principles)  developed  by  the  LVCAR  Study  that  should 
be  applicable  to  the  ADF  are: 

•  Do  No  Harm  -  No  immediate  action  to  discontinue  any  of  the  existing  simulation 
architectures  should  be  taken.  Rather,  as  the  differences  among  the  architectures  are 
gradually  reduced,  it  should  be  the  users  themselves  who  decide  if  and  when  it  is 
appropriate  to  merge  their  architectures  into  some  smaller  set  based  on  both  technical 
and  business  concerns.  Any  attempt  to  mandate  a  convergence  solution  on  an 
unwilling  user  base  is  certain  to  meet  strong  resistance  and  likely  to  fail.  This  is 
obviously  the  lesson  learned  by  the  US  DoD  from  its  attempt  to  mandate  HLA! 

•  Start  with  Small  Steps  -  The  DoD  should  take  immediate  action  to  improve 
interoperability  among  simulation  architectures.  LVC  users  need  near-term  solutions 
(improved  gateways/  bridges,  common  object  models,  and  common 
development/ execution  processes)  that  reduce  both  cost  and  technical  risk  until 
architecture  convergence  (over  many  years)  can  occur.  These  solutions  may  be  low  cost, 
and  provide  significant  near-  and  midterm  value  to  the  LVC  community; 

•  LVC  Interoperability  is  not  free  -  There  are  no  Net  Warrior,  DSTO,  or  ADF  corporate 
interoperability  standards  such  as  those  being  discussed  in  this  report!  Investments  to 
enable  the  activities  described  in  the  US  DoD  LVC  Roadmap  (and  discussed  in  this 
report)  need  to  be  made.  The  Roadmap  has  taken  a  long-term  approach  which  requires 
only  limited  investment  early  in  its  implementation,  with  subsequent  investments 
dependent  on  demonstrable  progress.  However  without  these  necessary  investments, 
the  LVC  Roadmap  is  nothing  more  than  a  blueprint  of  what  it  is  possible  to  accomplish, 
with  no  mechanism  to  realise  the  associated  benefits;  and 

•  Provide  Central  Management  -  A  centralised  management  structure  that  can  perform 
wide  oversight  of  M&S  resources  and  activities  across  developer  and  user  organisations 
to  prevent  divergence  and  enable  the  architecture  convergence  strategy,  must  be 
established.  This  team  needs  to  have  considerable  influence  on  funding  decisions 
related  to  future  LVC  architecture  development  activities.  Otherwise  existing 
architecture  communities  will  continue  to  treat  corporate  requirements  as  secondary 
issues  that  are  likely  to  be  ignored  as  concerns  that  are  not  relevant  to  higher  priority. 
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locally  funded  problems;  and  corporate  interoperability  development  may  only  occur, 
if  at  all,  in  an  unsatisfactory  (possibly  counter  productive)  ad-hoc  fashion. 
Interoperability  needs  to  be  appropriately  tasked,  resourced  and  developed  to  initially 
reduce  risk;  but  then  move  from  reducing  risk  towards  "Guaranteeing 
Interoperability"  which  is  far  more  difficult  to  achieve! 

A  set  of  five  potential  strategies  were  identified  and  investigated  by  the  LVCAR  Study: 

•  Status  Quo  or  "Do  Nothing"; 

•  Actively  Manage  the  Existing  Architectures; 

•  Convergence; 

•  Select  One  of  the  Existing  Architectures;  and 

•  Develop  A  New  Architecture. 

The  LVCAR  Study  recommended  two  of  these  strategies: 

•  Actively  Manage  the  Existing  Architectures  -  Create  standard  inter-architecture 
integration  solutions.  Keep  the  current  multiple  architectures  but  invest  in  improving 
the  construction  /  performance  /  integration  of  various  gateways,  translators,  object 
models,  and  create  processes  and  procedures  to  make  inter-architecture  integration 
"faster,  easier,  cheaper.";  and 

•  Convergence  -  Create  policy  and  procedures,  and  provide  small  amounts  of  seed 
money,  to  encourage  the  architectures  to  converge  with  one  another  in  the  long  term 
time  frame  (e.g.,  10  years).  When  they  become  so  similar  in  features  and  capabilities, 
engineer  the  merging  of  them  into  a  single  architecture. 

The  LVCAR  Study  also  recommended  a  set  of  interoperability-enhancing  activities  that 
include: 

•  Devise  common  components  of  architecture-independent  object  models; 

•  Produce  common  gateways  and  bridges; 

•  Create  a  common,  reusable  federation  agreement  template; 

•  Describe  and  document  a  common,  architecture-independent  systems  engineering 
process; 

•  Develop  and  /  or  use  common  tools; 

•  Implement  a  process  to  maintain  specifications  for  current  and  future  requirements; 
and 

•  Facilitate  pre-integration  systems  readiness  (ie  use  a  standards  based  approach). 

In  the  US  there  are  at  least  five  different  Advanced  Distributed  Simulation 
protocols/  architectures  in  use  -  DIS,  HLA,  TEN  A,  ALSP  and  CTIA.  Llowever  in  Australia, 
although  there  may  be  some  use  of  the  minor  architectures  (mainly  in  COTS  systems),  the  vast 
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majority  of  distributed  simulation  systems  are  DIS  or  HLA  systems  where  according  to  the 
LVCAR  Study  [LVCAR  -  1],  [LVCAR  -  2]: 

•  DIS  (Distributed  Interactive  Simulation)  has  a  comparatively  low  barrier  to  entry,  and  it 
is  relatively  simple  to  learn  and  easy  to  use.  Also,  it  imposes  a  very  low  overhead. 
Whenever  simulation  events  do  not  require  using  more  advanced  architectural  services 
(such  as  time  management,  region-based  information  filtering,  and  so  on),  DIS  offers  a 
very  economical  solution  to  the  system  intercommunication  problem;  and 

•  HLA  (High  Level  Architecture)  can  serve  a  disparate  collection  of  simulation  systems, 
including  those  that  require  advanced  architectural  services  and  those  that  have 
modest  requirements.  In  addition  to  its  large  U.S.  user  base,  its  standing  as  an 
international  standard  has  resulted  in  a  large  level  of  use  in  the  coalition  partner 
countries,  facilitating  combined  simulation  events  that  include  multiple  nations. 

However,  again  according  to  the  LVCAR  Study 

"DIS  should  only  be  considered  as  a  candidate  for  limited  convergence.  This  protocol 
provides  unique  services  and  capabilities  that  would  be  lost  were  the  protocol  to  be  fully 
converged  with  other  architectures  that  serve  different  communities  and  necessarily 
provide  higher  levels  of  service  capability.  While  some  of  the  activities  that  could  lead  to 
more  service-level  compatibility  (e.g.,  common,  components  of  object  models,  standard 
wire-level  protocols,  etc.)  between  DIS  and  the  other  architectures  will  prove 
advantageous,  DIS  should  remain  much  as  it  is  today,  a  lightweight,  core  capability 
protocol"; 

Therefore,  because  the  vast  majority  of  Australian  LVC  systems  are  DIS  or  HLA,  and  DIS 
should  remain  much  as  it  is  today,  the  US  LVCAR  Convergence  strategy  cannot  really  apply 
in  Australia.  DIS  and  HLA  will  simply  remain  as  two  separate  architectures  /  protocols  and 
both  will  have  to  be  supported. 

However  the  LVCAR  Actively  Manage  the  Existing  Architectures  strategy  "to  invest  in 
improving  the  construction  /  performance  /  integration  of  various  gateways,  translators, 
object  models,  and  create  processes  and  procedures  to  make  inter-architecture  integration 
"faster,  easier,  cheaper"  can  apply  in  Australia. 

This  current  report  focuses  on  the  common  object  model  component  of  the  Actively  Manage 
the  Existing  Architectures  LVCAR  Study  strategy.  Unless  LVC  systems  have  such  common 
object  models  (ie  common  data)  other  LVCAR  Study  recommended  interoperability 
enhancing  components  such  gateways,  translators,  etc.  will  not  work  as  there  will  be  no 
common  data  for  translators  or  gateways  to  work  on! 

The  objective  of  this  current  work  is  to  further  develop  an  ADF  Corporate  Synthetic  Range 
Interoperability  Model  (ie  a  set  of  ADF  Corporate  interoperability  standards  including 
common  object  models)  that  will  precisely  and  unambiguously  define  LVC  interoperability 
parameters  that  will  be  specified  when  acquiring  ADF  LVC  systems.  LVC  systems  that  are 
compliant  with  the  recommended  ADF  Corporate  Synthetic  Range  Interoperability  Model 
should  be  delivered  and  accepted  (after  appropriate  testing)  with  a  useful,  usable  level  of 
"Out-the-Box"  LVC  interoperability. 
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The  use  of  such  an  ADF  Corporate  Synthetic  Range  Interoperability  Model  will  result  in 
reduced  cost  and  risk  to  the  ADF  for  compliant  ADF  LVC  systems. 

Interoperability  among  LVC  systems  within  a  common  scenario  requires  compliance  with  an 
agreed  set  of  interoperability  standards  including  network  infrastructure,  data, 
interoperability  protocols,  platform  /  environmental  representation,  etc.  This  requires  the 
development  of  a  Synthetic  Range  Interoperability  Model  (a  set  of  interoperability  standards) 
that  is  a  crucial  part  of  any  synthetic  range  architecture.  All  LVC  systems  that  are  compliant 
with  a  particular  (ie  corporate  ADF)  Synthetic  Range  Interoperability  Model  should  be  highly 
interoperable  regardless  of  whether  the  systems  are  Live,  Virtual  or  Constructive. 

This  "Standards  Based  Approach"  architecture  will  provide  a  high-reliability,  routine,  robust, 
scalable  and  reliable,  global,  LVC,  daily  training  capability  for  the  war-fighter.  The  USAF 
Distributed  Mission  Operations  (DMO)  is  based  on  this  standards  based  approach 
philosophy. 

Once  a  Synthetic  Range  Interoperability  Model  (ie  interoperability  standards)  has  been 
precisely  and  unambiguously  defined,  common  RFT  specifications  and  test  and  acceptance 
procedures,  to  enable  accreditation  for  that  particular  Synthetic  Range  Interoperability  Model, 
can  be  developed. 

LVC  systems  cannot  participate  in  exercises  unless  appropriate  accreditation  has  been 
obtained. 

Compliance  with  a  Synthetic  Range  Interoperability  Model  does  not  restrict  additional 
enhancements  for  specific  LVC  systems. 

All  specifications  defined  in  a  Synthetic  Range  Interoperability  Model  must  be  mandated! 

All  relevant  Synthetic  Range  Interoperability  Model  parameters  (including  the  initial  Common 
Object  Model  comprising  DIS  PDUs,  DIS  PDU  data  fields  (or  their  HLA  equivalents),  and 
enumerations)  must  be  mandated  for  "Out-The-Box"  interoperability  to  be  maximised. 

Unless  such  a  standards  based  approach  (ie  mandating  an  ADF  Corporate  Synthetic  Range 
Interoperability  Model)  is  adopted  ADF  LVC  interoperability  will  be  difficult  to  achieve! 

For  virtual  or  constructive  simulation  systems  (ie  no  Live  systems)  the  Synthetic  Range 
Interoperability  Model  can  be  simplified  further  by  requiring  that  only  the  SISO-J  transport 
protocol  [SISO-STD-002-2006]  be  supported  for  Link-16  Tactical  Data  Link  interoperability. 
The  model  then  reduces  to  that  shown  in  Table  5  and  Figure  5  where  compliance  with  this 
model  can  be  fully  achieved  using  only  DIS  or  HLA.  In  this  situation  specialised  Tactical  Data 
Link  hardware  and  software  is  not  required  (or  at  least  reduced)  because  SISO-J  is  supported 
in  DIS  or  HLA  thereby  reducing  considerably  the  tactical  data  link  software  and  hardware  (ie 
cost  and  risk)  required  for  such  systems. 

The  ADF  Corporate  Synthetic  Range  Interoperability  Model  proposed  in  this  current  report 
appears  to  be  very  similar  (if  not  identical)  to  the  Synthetic  Range  Interoperability  Model  used 
by  the  USAF. 

In  AOD  the  proposed  AOD  DMO  compliant.  Mission  Training  Centre,  Capability  Concept 
Demonstrator  [Zalcman  (2010)]  (comprising  the  AOD  ADGESIM,  DACS  and  AEW&C  WIRE 
systems)  and  the  DSTO  Net  Warrior  initiative  [Filippidis]  could  both  contribute  to  the 
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development  of  an  ADF /RAAF  Synthetic  Range  Interoperability  Model.  However  both  these 
programmes  must  be  appropriately  resourced  and  funded,  and  corporate  interoperability 
must  be  made  a  high  priority. 

Both  these  DSTO  programmes  would  be  natural  sponsors,  developers,  consumers  and  testers 
of  such  DSTO  developed,  corporate  LVC  interoperability  standards. 

The  AOD  developed  ADGESIM  and  DACS  systems  may  already  be  fully  compliant  with  the 
recommended  corporate  ADF  Synthetic  Range  Interoperability  Model  -  certainly  at  the  DIS 
PDU  level. 

The  AEW&C  WIRE  system  is  currently  being  analysed  to  see  if  it  can  be  made  compliant  with 
the  recommended  corporate  ADF  Synthetic  Range  Interoperability  Model. 

Once  an  appropriate  set  of  corporate  LVC  interoperability  standards  have  been  developed,  a 
corresponding  set  of  Test  and  Acceptance  (T&A)  compliance  procedures  will  also  need  to  be 
developed. 

The  ADGESIM  and  DACS  systems  should  then  be  "tested  and  accepted"  (ie  accredited) 
against  the  AOD  Corporate  LVC  interoperability  standards  using  the  associated  Test  and 
Acceptance  (T&A)  compliance  procedures. 

Experimental  DMO  exercises  should  be  carried  out  using  accredited  systems  to  see  if 
interoperability  problems  are  reduced. 

This  interoperability  standards  development  cycle  should  continue  until  a  "stable  level"  of 
interoperability  has  been  achieved. 

A  set  of  RFT  specifications,  that  could  be  used  to  specify  ADF  systems  requiring  LVC 
interoperability,  could  then  be  developed.  This  process  would  then  hopefully  move  the  ADF 
from  reducing  risk  towards  guaranteeing  interoperability  for  acquired  ADF  LVC  systems. 


13.  Recommendations 


The  recommendations  from  this  study  are: 

Recommendation  1:  An  AOD  Corporate  Synthetic  Range  Interoperability  Model  should 
continue  to  be  developed. 

Recommendation  2:  The  AOD  Corporate  Synthetic  Range  Interoperability  Model  should 
support  both  DIS  and  HLA  (by  use  of  the  HLA  RPR-FOM). 

Recommendation  3:  The  AOD  Corporate  Synthetic  Range  Interoperability  Model  should 
include  common  object  models;  common  gateways  and  tools;  and  common  federation 
agreements. 

Recommendation  4:  The  initial  AOD  Corporate  Synthetic  Range  Interoperability  Model 
interoperability  standards  should  define  the  required  common  object  models  including  DIS 
PDUs  (already  done  in  this  report),  common  DIS  PDU  data  fields,  and  a  set  of  common 
Enumerations  (future  reports). 
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Recommendation  5:  This  initial  set  of  AOD  Corporate  Synthetic  Range  Interoperability  Model 
common  object  models  (eg  DIS  PDUs  for  DIS)  should  form  the  basis  of  the  common  object 
models  of  an  ADF  (or  RAAF)  Corporate  Synthetic  Range  Interoperability  Model. 

Recommendation  6:  Once  developed  the  common  object  models  of  an  ADF  (or  RAAF) 
Corporate  Synthetic  Range  Interoperability  Model  must  be  mandated  for  all  ADF  (or  RAAF) 
LVC  system  acquisitions  otherwise  ADF  (RAAF)  LVC  interoperability  will  be  difficult  to 
achieve. 
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